Future of D 2.x as stable/bug fix, and what's next for D 3.x

[Ola Fosheim Grøstad]

On Friday, 4 September 2020 at 07:08:40 UTC, Russel Winder wrote:
> Investing in Rust means investing in the non-GC mind-set. It is 
> easily done, and has many benefits in many areas of software 
> development.

I'm sure their approach works well for larger teams, but when you 
look closer at what people do to get beyond tree-like structures 
in Rust they essentially end up using array-indexes as pointers. 
So technically it is memory-safe, but then you are basically back 
to square one in terms of correctness and also pay some 
performance penalty (out-of-bounds checks).

> My feeling is that C++20 and C++23 are likely to satisfy C++ 
> addicts such that any thoughts of using D get washed away.

It does make the languages/standard lib more similar in some 
ways, I guess.

> I have no problem iwth D trying to be both GC and non-GC for 
> those D programmers that feel they need it, but D is very much 
> seen fairly widely as a GC language, I see no reason to fight 
> that.

Well, but the D language semantics does not provide a lot of room 
for optimizing a GC runtime. So being competitive in terms of GC 
capabilities would require a D3.

> I am not sure Go is cutting into C++, but I am a bit out of 
> that arena just now with no ACCU conferences this last year. Go 
> is certainly taking some of the old Java stuff, mostly to do 
> with containers, etc.

You can write a better image-rescaling service in C++ or D, but 
since Cloud infrastructure makes it easier to deploy managed 
languages lik Go, then that makes me more likely to pick Go. E.g. 
you can run Go as a Google Cloud Function, but for C++ you have 
to set up a docker-thingy.

Also, setting up a web-service with Go is less hassle, as more is 
available in the standard library/runtime. So even though I might 
prefer to do it in C++/D it would take twice as much effort, and 
require somewhat more maintenance. So even though Go loose on 
performance, it might win on less friction and effort.

Like, with C++/D I will have to figure out which HTTP-server 
library to use, basically more manual labour and things that 
could go wrong.

But apparently has become easier to deploy smaller languages with 
Google Cloud Run. So if someone created a github repo with a 
ready-made "template" for D, then that would make it more likely 
that people would use it.

> Do not underestimate Python as a way of developing GC Web 
> servers.

True, and with the "cloud functions" approach you get to use 
different languages for different requests. So the situation is 
more flexible than it used to be.