Future of D 2.x as stable/bug fix, and what's next for D 3.x
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Fri Sep 4 08:17:04 UTC 2020
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
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
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
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.
More information about the Digitalmars-d