D is dead

[nkm1]

On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh 
wrote:
> Let's start with this one:
> https://issues.dlang.org/show_bug.cgi?id=14246#c6
>
> The problems I'm talking about are not easily fixable. They 
> stem from features not playing well together.
>
> One that hurt me lately was a way to pass a scoped lazy 
> argument (i.e. - to specify that the implicit delegate need not 
> allocate its frame, because it is not used outside the function 
> call).

The only real problem with D is that it's a language designed with
GC in mind, yet there are numerous attempts to use it without GC.
Also, supporting GC-less programming gets in the way of improving
D's GC (which is pretty damn bad by modern standards).
That's the only real technical problem.
For example, the "bug" above just means that D doesn't support 
RAII
(in the C++ sense). That's hardly a *fatal flaw*. Lots of 
languages don't
support RAII. Python, Java, C# - tons of code were written in 
those.
And yes, most of those just use GC to dispose of memory - other 
resources
are rarely used (compared to memory) and it's not a problem to 
manage them
manually.
You also mentioned lazy parameters allocating... GC thing again. 
Just
allocate then? No?
IMO, if getting the maximum number of users is the main goal, D 
is indeed
going the wrong way. It would be better to get rid of @nogc, 
betterC, dip1000,
implement write barriers and use them to improve GC. Martin Nowak 
(I think)
mentioned that write barriers will decrease performance of D 
programs by 1-5%.
Seems like a small price to pay for better GC with shorter 
pauses. It would also
probably be simpler technically than stuff like dip1000 and 
rewriting Phobos.
Of course, maximizing the number of users is not the only goal, 
or even the
main one. My understanding is that Walter wants a "systems 
language" with
"zero cost abstractions". Well, it's very well possible that D's 
design
precludes that.
Other than memory management, I don't see any real fundamental 
problems.