Nim programming language finally hit 1.0

[Paulo Pinto]

On Wednesday, 25 September 2019 at 14:29:19 UTC, Chris wrote:
> On Wednesday, 25 September 2019 at 11:02:57 UTC, IGotD- wrote:
>>
>> In my opinion Nim is one of the closest competitors of D 
>> because they are both runner up languages and they try to 
>> focus on productivity. Right now Rust seems to be influencing 
>> D a lot but I think if you want to look other languages, you 
>> should definitely also look at Nim.
>
> The problem of D has always been that it constantly follows the 
> fashion of the day. First it was trying to "beat" C++, then it 
> was competing with Go, now it's Rust. What's next? I find it 
> refreshing to see languages like Nim and Zig that try to base 
> their decisions on what works and what doesn't, what makes 
> sense and what doesn't, not on Reddit threads about the latest 
> CS fashion. Given that D has introduced a nice set of promising 
> features of its own, I don't understand why D is constantly 
> trying to emulate other languages, before it's even clear 
> whether feature X will work or not. I think languages like Nim 
> and Zig do have a chance, if they avoid D's mistakes and focus 
> on their strengths. Usefulness and consistency are of utmost 
> importance.

Definitely, on my case what D offered me, not available in either 
in Java or .NET, has in the mean time been sorted out.

C# 7.x low level features, .NET Native and CoreRT, having F# and 
C++/CLI as additional companion, and while annotations + 
expression trees and F# computations aren't as straightforward as 
D's metaprogramming, they get the job done.

Likewise Java is getting value types and a JNI replacement, 
GraalVM is an wonderful piece of technology, battle tested by 
Twitter, with NVidia now adding CUDA support, and annotation 
processors and reflection also offer good enough metaprogramming, 
even if like on .NET's case they aren't as developer friendly as 
D's.

C++20, regardless of the backwards compatibility baggage it 
brings along, also offers many of the features that made D 
noteworthy and keeps being the tool to go when Java, .NET need an 
extra help.

Then on Apple's platform I am an happy Swift user.

While I still advocate D for safe systems programming, its story 
needs to be more coherent.

And regarding the latest DIP discussions, if D veterans have 
issues trying to make sense how they are supposed to work, what 
hopes have newly D adopters?

The broken features should be sorted out, and be proud of being a 
GC systems language.

That is what I appreciate in Go and Nim, they have their story, 
with GC, and stand by it, even if that alienates some crowds.

So even if Go is not supposed to be a systems language, there are 
Google projects using it like that (gVisor, Android GPGPU 
debugger, Fuchsia TCP/IP stack).

The language should be stabilized, GC improved (I know it has 
gotten much better), replace deprecated Phobos packages (xml, 
JSON, stream), focus on vi/Emacs/VSCode and maybe people will 
come and stay around.

Trying to cater to the crowds that flock to the systems language 
of the month is damaging for D's future, at the end the only 
thing left is patting each other in the back while asserting 
"language X might have won, but D had it first".