11–20 of 186 posts
Any reasons D never caught on more? No big tech company anchor behind it?
Earlier quoted context omitted.
Challenging to overcome languages like C++, Rust, Java, and C#. D seems to sit somewhere in between, a better C++, but with (optional) GC. The thing is, Java and C# are already making strides into that space.
I am curious to see where Java are C# are making progress towards optional GC. This specific article talks about using No GC aka "betterC". D has GC by default; the use of GC is convenient and mainstream as most popular languages show - Java/C#/Python etc. What D gives is the unique ability to do No GC programming for the cases where GC is not desirable. Very few languages offer this capability. Zig is interesting in…
Granted, this isn't optional GC, but does D really give you that? Don't you lose the entire ecosystem and stdlib with -asBetterC? Why would I choose that over rust/zig/c++?
FWIW, I am a big fan of D.
[0] https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/...
I have to go to bed, I have work in about 4 hours, so I'll reply when I can.
Any reasons D never caught on more? No big tech company anchor behind it?
Challenging to overcome languages like C++, Rust, Java, and C#. D seems to sit somewhere in between, a better C++, but with (optional) GC. The thing is, Java and C# are already making strides into that space.
Hi, I'm the author of the article. Feel free to ask any questions you may have. I have to go to bed, I have work in about 4 hours, so I'll reply when I can.
That being said, is there maybe somewhere a more thorough write-up about the whole thing? You know, with more in-depth technical details, gotchas, and so on? I'm sure many people would enjoy reading that!
Thanks for posting!
Any reasons D never caught on more? No big tech company anchor behind it?
- More powerful metaprogramming capabilities.
- Better module and library system.
- Nicer syntax.
The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language.
Furthermore, many of the other downsides of C++ are still present:
- The complexity of the language, and then the sheer number of different ways of doing the same thing.
- Some pretty dark corners in the way stdlib/language feature were implemented that seemed hard to ever fix.
- The way behaviour is specified in the language is very tied to the underlying hardware: rather than explicitly describing behaviour in terms of an abstract machine, it works more in the way C++ is specified where we all know it operates on an abstract machine thanks to compiler optimizations, but the spec likes to pretend it doesn't...
And then there are problems that are introduced by D, such as the fact that a safe subset exists, but depends on GC, so there's a weird split where no "safe code" can be used in contexts where GC is unsuitable.
Contrast this to Rust, where:
- There is a true step-change in bringing safe code to all contexts, not just those where GC can be used.
- It's missing a lot of the complexity of C++. Rust is hard because it has concepts that are foreign to a lot of programmers, but the total number of features is low (compared to C++) so there are fewer surprising ways they can interact.
- Rust is a suitable replacement for C, not just C++, because it's not just adding more features.
UFCS example uses units, which looks neat, but assigns injectorWidth to a variable injectorTime, which seems wrong?
Any reasons D never caught on more? No big tech company anchor behind it?
I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: -…
UFCS example uses units, which looks neat, but assigns injectorWidth to a variable injectorTime, which seems wrong?
Injector width / time pretty much means the same thing (at least in my code base). My apologies for the confusion.