SoylentNews is people
SoylentNews
from the Obfuscated-Rust-Competition-doesn't-sound-right dept.
In spite of my status and obvious bias as co-creator of D, I'll do my best to answer candidly; I follow Go and Rust, and I also definitely know where D's dirty laundry is. I'd encourage people with similar positions in the Rust and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be replaced alongside C, or be one of the candidates that's supposed to replace C, the C++ language is a key part of the equation. It's the closest language to C and the obvious step up from it. Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement.
Each language has a number of fundamental advantages (I call them "10x advantages" because they are qualitatively in a different league compared to at least certain baselines) and a number of challenges. The future of these languages, and their success in supplanting C, depends on how they can use their 10x advantages strategically, and how they overcome their challenges.
[Another way to look at this is to ask "What is wrong with C?" and then assess how well these languages solve those problems. -Ed.]
(Score: 4, Insightful) by Wootery on Friday November 13 2015, @04:47PM
I generally really like D, but it suffers from one big problem far worse than most other semi-big languages: language stability. Grown-up languages shouldn't be fickle.
It seems to make breaking changes all the time for little benefit. If you want to compile a major D project (like say vibed), you have to have exactly the correct version of the D compiler, or it just won't compile. If you use a too-new compiler, you're likely to hit a build error.
Additionally, they're too quick to add new features, without properly thinking them through.
A random pet-peeve for good measure: silliness like the 'lazy' keyword, which is implemented in such a way that at the call-site you have no idea when or if your parameters are going to be evaluated. (You see a similar case of 'compiler lying' in C# attributes, where functions are 'helpfully' made to look like member variables.)
Oh, and the truly obscene amounts of memory that a build can require (i.e. gigabytes). You see this in C++ too (I'm looking at you, Firefox) but only when your build-system and project layout are total crap. In D it's unavoidable. Well, unless you carefully avoid the language features that cause compile-time memory explosion.