Nim programming language finally hit 1.0

[Chris]

On Monday, 30 September 2019 at 07:07:34 UTC, JN wrote:

>
> This is true. However, given that it's a volunteer project, 
> there is room for improvement. If the workforce is limited, 
> it's spread over the language/libraries surface. If we were to 
> minimize that surface, we can have more work done.
>
> I think D shouldn't be afraid to cut some of the language 
> features which aren't used much, or have a viable workaround. 
> This way the language would be smaller and easier to 
> maintain/bugfix. Also, smaller language means lesser chance of 
> bugs occuring in the first place. Right now I feel like D is in 
> that weird spot. It's too afraid to cut or rework existing 
> features for language stability, but then is too brave 
> introducing new concepts which weren't battle-tested before.
>
> Main issues with D aren't with the specific features, which 
> often came up as a good idea and solve some problem, but the 
> problem is when these features interact with other features. 
> The result is a lot of unexpected interactions (look at any DIP 
> discussion thread, there's always a case of "yeah but this 
> breaks if I have an immutable shared union with alias this"), 
> added cognitive load for the programmer and harder to write 
> generic code.

I agree. New features are introduced way too fast, often based on 
the latest CS fashion of the day ("Look here's a paper on...")  
or "Rust has it, so we need it too!", regardless of whether or 
not this will break code. Maybe the reason why (ex-)users 
(including myself) are sometimes so grumpy and negative is that 
this implicit disregard of users' code makes users feel as if 
they and their work didn't count at all, yet D complains that 
there aren't enough users, yeah right. I don't know about others, 
but when I was still using D actively I would sometimes see 
discussions on the forum and say "Holy sh*t! Does this mean I'll 
have to refactor my code once this new feature becomes part of 
D?" It's like programming on an ejector seat, and after a while I 
got just sick and tired of it. Nobody wants to live like that 
forever, not to mention that it is really annoying if you have to 
go back to old code to "fix" things that shouldn't be broke in 
the first place. Ah, c'mon.

D is 20 years old and still the same criticism pops up again and 
again and again and the same answers are given: volunteer effort, 
do it yourself or PFO. Is it the users' or the language 
leadership's fault I wonder, after 20 years. Hm.

D is theoretically in a good position to do a spring cleaning. It 
has loads of features. Take what really works (battle-tested 
features), drop all the half-baked features that only a minority 
really uses. Improve the stability of the language and set up a 
proper ecosystem (e.g. out of the box compilation for various 
platforms / architectures).

Atm, I'm mainly using Kotlin and I have to say that a small set 
of clever and well thought-out features can get you a long way. 
Do I miss some of D's features? Not really, because Kotlin 
provides enough useful and battle-tested features that you need 
90% of the time [1]. Once I missed `static if`, but I could live 
without it.

Mind you, Kotlin has some restrictions due to the fact that it 
has to be a 100% compatible with Java/JVM. But even when you use 
Kotlin/Native (without the Java universe, i.e. modules and 
libraries) you can get quite far. I think D should aim at that.

1. Take D's great features that are battle-tested
2. See what is not strictly necessary and drop it (dead weight), 
i.e. figure out what programmers need 90-95% of the time and 
don't pollute the language with features you only need in the 
remaining 5-10% of the cases.
3. Set up a sound and stable ecosystem

But then again, I fear this will never happen.