Origins of the D Programming Language

[Adam D. Ruppe]

On Saturday, 1 December 2018 at 08:22:57 UTC, Paolo Invernizzi 
wrote:
> It was renamed just for clarity, when someone got confused 
> about it, the explanation was always something like "it's 
> simple an immutable value, like ROM"

Indeed. It was invariant to avoid making a new keyword, but since 
invariant() and invariant(stuff) ended up meaning something 
different, and people kept saying "what is an invariant variable" 
and the answer was "it is immutable"... they just changed it to 
immutable.

Now, the addition of this was not the split point of D1 and D2 
(though I would point out that split was more like a version 
forked off and called itself D1 while the language in general 
kept changing like it always had - the article there called it 
"arbitrary" which is totally true), but it was really close to 
it, like a couple months later, and I consider it to be the main 
breaking change of that "era" (in addition to a bunch of 
functions being renamed in Phobos, which was really annoying but 
less fundamental). Very little code before and after the addition 
of invariant would actually still work, since the type of string 
changed!

(Though again, invariant/immutable was actually added *before* 
the type of string actually changed; there were a few releases in 
this process.)



The other notable thing though was how all this stuff I think is 
so analogous to the memory safe talk of today. Thread safe by 
default was a huge talking point. For a couple years, everyone 
was throwing out fancy proposals, tons of major stuff was added 
(including several big breakages), the TDPL book was published 
promising more like `shared` meaning something. We were told this 
is the future of programming - multicore is the big thing, no 
more serial processors. If D is going to go anywhere it MUST 
capture this. Comparisons with Erlang all around.

But where are we now? Those features are there... but were they 
the revolution? I'd say no. In fact, most people seem to simply 
ignore them and carry on.


And now, memory safety is trumpted as the next big thing that D 
MUST capture. Comparison with Rust all around. (Never mind that D 
has basically already solved memory safety with a well-known, 
widely-implemented traditional solution: conservative garbage 
collection.) Many features being added.

But where do you think we'll be in five years? I know my guess.