D Language 2.0

[bearophile]

Daniel:

I answer to just the things I know and understand, and I leave the other points to other people, sorry.

> D still takes 80kb just to print "hello world" to the prompt.

When D2 is out of alpha for some time, I think devs will start to think about this problem too. Currently it's low priority, because the language isn't finished yet :-)


>I went to write a small program for an embedded device, but because of this I had to
> abandon and rewrite it in C

I am not sure D2 will be fit for embedded devices... even 32 bit ones.


> D is still aimed at the i486, and is just starting to handle threading.  My CPU is a Core i7, which is a quad-core. It also has SSE4.2.  It's been 20 years.<

LDC compiler (D1 still) manages SSE registers well (here the problem is the opposite, it's the x86 FPU that's badly used, but most times today this doesn't matter much).
When D2 is out of alpha, I presume some people will create a D2 compiler based on LLVM with good SSE support.
Regarding multi-processing, it's being worked on now.


> cent and ucent should be available via SSE.<

LLVM already supports such values, so I think it's not a hard work to add them to ldc. The problem is that I don't often need to sum 128 bit signed integers. I may need to perform a bitwise && among SSE registers, but you can't tie a language to the width of the current CPUs. What if tomorrow the registers become 256 or 1024 bits wide? D language must be used 10 years from now, when you have 2048 bits wide registers too, you can't keep adding wider and wider built in types. It's better to have a way to represent bit arrays and to perform bitwise operations among them, as LLVM already does. Wait, that's what array operation syntax is already designed to do :-) They just need to be implemented better (so for example if the compiler knows that two fixed-sized arrays of 256 bits each are && together, then this needs to implement it with two inlined SSE bitwise ops). This doesn't require a language change, but a bit better optimization stage, it's a matter of language implementation, not language design. So what are the purposes of a true cent/ucent type again?


>Don Clungston had some excellent code written up in BLADE found on dsource 2 years ago.  Shouldn't that have become part of D native?<

Things change, as time passes.


>I also kind of hoped we'd see standard real world unit types in D.<

A mostly std lib solution can be acceptable, if there's a bit of support from the language. I am sure Andrei doesn't want to do what was done for complex numbers.
The problem is that I don't like solutions on both extrema: I don't like complex numbers to be fully lib-based with a raw syntax, and I think I don't need them fully built-in that increase compiler complexity. So I'd like just a bit of support from the language to improve the syntax of unit types.

Two times in the recent past NASA has broken things because of programs that have mixed miles with kilometres and similar things. With a language that enforces unit types very well, such class of bugs can be avoided.

Bye,
bearophile