D is dead

[Ecstatic Coder]

On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
> 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.

+1

Making D a "true" C++ competitor is not going to happen soon.

Even Rust, which IS by definition a true C++ competitor (no GC, 
etc), will still find it very hard to replace C++ in its current 
niche markets, like embedded and game development.

While putting all the "funded" efforts in making D a *direct* 
competitor to GC languages (like Go, Crystal, C#, Java, etc) 
would be an achievable goal, IMHO...