Disadvantages of building a compiler and library on top of a specific memory management scheme

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Saturday, 8 February 2014 at 17:08:44 UTC, Daniel Murphy wrote:
> Not in theory, but it's like saying we shouldn't design the 
> language based on semantics of existing processors, because it 
> will lead to non-optimal performance on quantum computers.

No, my focus is on what can run efficiently on hardware that 
exist and is becoming prevalent in the next 3-5 years. I want a 
system language focus that allow you to write efficient servers, 
that in the future will work well with cache level 1 
transactional memory and other goodies that are coming. A 
language that makes it easy to write fast, robust OS-free servers 
with fixed memory allocation that you can upload as VMs so that 
you can have stable "game servers"/"web services" that are 
performant, stable, and cost efficient.

No such language exist, a more focused D effort could take that 
niche and the future embedded space, I think. But you need to 
break away from C, C++, Java and C#.

IMHO C-semantics is stuck in the 1960s. x86 is to some extent 
geared towards making it easy to make C-semantics more efficient, 
but you can easily get better performance by going to the machine 
code level in terms of structure. What is difficult today is 
specifying such structures, so people end up with more efficient 
C-semantics (like doing FSM in C rather than in a manner that is 
optimized for the hardware).

>  The fact these tools/hardware/backends already exist is worth 
> a huge amount in producing a language that is useful, even if 
> not optimally optimal.

Sure, but that should not drive the language spec. That way you 
will never get the upper hand, you will never become more 
attractive than the competition. You can usually create 
reasonably efficient alternatives where the C-backend isn't 
cutting it in a proof-of-concept manner (like having extra data 
structures that you maintain on the side, or using DWARF for now, 
but admit that it is not your goal/standard!). I think the long 
term goal should be to have a backend that provides stuff that 
the C crowd does not have. Maybe when D is implemented in D you 
can move in that direction.

D2 smells too much of "C++ with opinionated restrictions" with 
C#/Java stuff thrown in without really making OS level system 
programming more attractive.

Unfortunately Go and Rust are currently also in that opinionated 
state that makes them atm not useful for systems level 
programming. And C/C++ is too unsuitable unless you have a lot of 
resources. But Go and Rust are more focused at a particular usage 
scenario (webserver/web browser) and their language design is 
thus focused. I think that is an advantage for them.

I think D could steal the VM/OS/embedded space with a very 
focused effort. C/C++ is ahead, but I believe D can surpass that 
if you go beyond C/C++ and forget about pleasing the Java/C# 
crowd.