Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I was sad that D never took off. I had high hopes that it would eventually replace C++ for my professional development. D was a language that really enabled functional programming, and I mean real functional programming while retaining the low level control of C.

We learned a lot from pushing D, and now I am working full time as a Rust developer. Rust doesn't have everything D has, but it also has plenty that D doesn't have and it's still in the same spirit of safer, more expressive C++ with the same efficiency. I hope that D developers will check out Rust and try to push a single front, I think it has a better chance of knocking C++ off its pedestal.

View on HN

>Rust doesn't have everything D has, but it also has plenty that D doesn't have and it's still in the same spirit of safer, more expressive C++ with the same efficiency.

And no GC, which is major for my hopes that it might be a viable alternative for us forgotten embedded programmers out there. LLVM seems to be a good backend for getting more embedde support in the future as well.

Rust for me has almost everything I expect from a "better C++", the Cargo project management is stellar, rustup is great for staying up to date, integrated testing and benchmarking is amazing. I just find there's still a lack of crates which should solve itself over time and a bit of a lack of good documentation (outside of the basic Rust language resources most crates are very hard to understand looking at docs.rs, which is especially sad given how well integrated documentation is).

There's lots of great stuff for embedded in Rust now too, you can no_std and use core, the new panic stuff. IMO it's awesome to write a language and do some more 'advanced' type stuff like add compile time safety with phantom types and stuff have it compile and run on an embedded device. The interesection of features there is great.

The critical faults with D that prevented it from displacing C* were that it relied on a GC by default and that it wasn't open source. Things might have played out much differently had they addressed these issues early on.

* aside from inertia, but older languages also had inertia once.

It's been open source for 10 years now.

And the BSDs have mostly moved passed the era of legal ambiguity that plagued them early in their development. For better or worse, timing and initial impressions count.

The only issue with the GC is the implementation could get some improvements.

Mesa/Cedar, Oberon and its variants, Modula-3, Sing# and System C# might have fallen, but we still have Swift, Go, .NET Native/C# 7.3, Kotlin/Native, Nim, Crystal and Chapel, besides D.

Not all hope is lost for those of us that belive on system languages with GC support.

> The only issue with the GC is the implementation could get some improvements.

jake_the_third's point was that until relatively recently, it wasn't practical to use D without using its GC. Some folks don't want GC. Some proportion of them have good reasons.

I'm not really keeping up with D these days but I believe the "@nogc" attribute has come a long way to making it practical to use D without GC - https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

I actually like that it has a GC, it has made programming in D easier and more accessible for me. It's also a simple GC that you can force to behave if you know how. D has the @nogc attribute for the situations where one would want to disable the GC and use something else.

https://dlang.org/blog/the-gc-series/

D is faster to compile, 3 backends, easier to start with, more expressive metaprogramming, optional runtime and GC, compile-time duck typing, Visual Studio debugger, grassroot "agnostic" community, very pleasurable and productive language. Companies have built their entire infrastructure on it, to great success.

So there is no incentive to use Rust.

I think there's a subtle fallacy about functional programming vs low level. Mostly due to the usual benefits of garbage collection style of memory management. But I find stack languages very functional in nature, it's when things grow and you start using lots of data structures that you lose sight of fp principles. Especially if you consider that FP Map/Reduce will be provably compiled to a cute choreography of localized (globally invisible) side effects. I'd like to claim that pre 80s programmers were doing a lot of that by hand without thinking about it.

Reply on news.ycombinator.com