Java and C# are statically typed, garbage collected languages with a huge adoption and massive amounts of tooling.
D's attempt to become an alternative to C and C++ was eclipsed by Rust, which doesn't have the GC overhead and has a ton of other really compelling features.
There are a bunch of other new and exciting languages too: Go, Nim, ...
Why would anyone choose D today? (Serious question.)
Rust isn't just a better C++, it imposes a new paradigm over resource management (lifetime oriented programming?). If you're coming from C++, you have to change your way of thinking. D doesn't try to make you follow any paradigm (for the better and for the worse) ; and its syntax will feel natural and terse for a C++ programmer.
My experience (10 people team) has shown all C++ programmers can learn D very quickly. Is this the case for Rust?
> Why would anyone choose D today? (Serious question.) Native speed, on-demand deterministic destruction, on-demand memory safety, metaprogramming, fast compile times, terse syntax.
A major pain point probably is that people never really followed the "conventions" of C++ resource management as rigidly as Rust enforces them.
That's exactly right. Rust does a great job moving idiomatic C++ best practices into the type system and actually forcing you to do it "right". And alot of the early pain people run into when switching to Rust is learning how to do this. I suspect very experienced C++ programmers have alot less challenge getting spun up on Rust. It's sorta front-loading the pain of discovering and learning C++'s best practices.
As a side effect, though, it means alot of Rust evangelism misses the mark as it mostly reveals their own C++ weaknesses (this is, on a different level, an indictment of C++, and its learning curve, but not really in the ways the evangelists often believe).
Compiles(with DMD, ldc and gdc are still fast but are not as fast) are fast and
D is not really comparable with Go (For example). D is much more complex (and I my opinion simpler to write through said complexity, but obviously opinions differ), whereas Go is supposed to be simple to learn and implement.
I considered C/++, Rust, Go, Nim and D.
D won because:
* Less manual memory management
* Awesome compile-time errors (this is absolutely key)
* Super easy tooling setup
* High-level abstractions in stdlib
* Still reasonably fast
* AOT compiled, which was a hard requirement for what I was researching
D and it's errors were just easier.
Not to say Nim isn't on my radar for new things, it just didn't quite fit at the time. (However, my first prototype was in Nim!)
Unfortunately not, as I no longer have the right to publish it, and it hasn't appeared in the journal yet.
But basically, partial evaluation of the AST to create a fully type-inferenced statically typed F-expr Lisp. Makes JITing faster.
a thesis, just produce a proof of concept
D is unpopular , and I really believe that going after c++ was a bad idea .. if this was not clear at first, it should be clear by now, yet almost 100% of the article i see on D never stop from claiming how much better it is compare to c++
I guess the lesson learned from D's unpopularity is, when creating something dont focus on one competing tool
I recall how one time Linus Torvald, bashed subversion on how "Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System" -- Wikipedia
Was a horrible design choice from the start
By focusing on C++ they added a GC, as an advantage (because C++ didnt have a GC) but now that many people priase Rust for not having a GC and arguing they prefer C++ over D for it ... now they are trying to dis-integrate the GC ... very reactive, design decision ... and i doubt this will help much
And I see the same from Rust and Go communities, hell I see it in Swift and Java communities a fair bit too.
That's not a real argument for or against a language. It just says the community will actually compare itself to other languages in similar fields. X vs Y articles are dime a dozen.
Some of Ds library inspired things in the new C standards, and D is influenced by other languages. I fail to see how that is a bad thing.
Common Lisp influenced Closure.
CoffeeScript influenced ES2005.
C has influenced Go.
Python, Nim.
That's just natural evolution. A language trying to become more flexible, is a good thing.
C++ is an incredibly popular collection of footguns and its replacement is a noble design goal.
Conversely, SVN is one of the tools which I use to archaeologize within a C++ codebase. It might not be right for the Linux kernel or other FOSS projects, but in the corporate world it works fine.
Really? So like your abstract goes in the main function, or how does that work? Do you use reference types for citations or just external symbols?
Good choice of language; though, who wants a "Ph. C++" or "Ph. Rust" affixed to their name, know what I mean?
I used a combination of Literate D [0] and pandoc to create the finished paper.
Ph. PLT still really doesn't stand out.
D has a documentation generator (Ddoc) as part of the language. It turned out to be useful as a standalone documentation generator. The dlang.org website is built using Ddoc, and I've even published a couple books in Ddoc. It feels a bit weird running a compiler over your marked up text, but that feeling passes after a while :-)
i think, it might be worth it if you guy investigate areas like these, many trading platforms have interfaced to c/c++ if D and be added as a drop in replacement, with some more safety guarantees, you have a big niche market here that D can survive on for a long time
1. Java and C# are designed around JIT compilation, which results in a number of architectural choices that may or may not be to your liking.
2. The JVM and CLR are pretty heavyweight pieces of machinery.
3. Neither Java nor C# are particularly well-suited for working "close to the metal".
> D's attempt to become an alternative to C and C++ was eclipsed by Rust, which doesn't have the GC overhead and has a ton of other really compelling features.
This goes both ways: Rust doesn't have a GC, so if you want one, you're out of luck. For example, for most of what I'm doing – where GC works fine –, Rust offers me no benefit, but significant costs (note that this is a matter of application domains: the ones that Rust is designed for are simply not ones that matter much to me).
> There are a bunch of other new and exciting languages too: Go, Nim, ...
Go and Nim are indeed the languages that D is competing with more directly, but there's nothing wrong with having competition in this area, given that all of them are relatively new.
The reflection is IMO the killer individual feature (well, hand-in-hand with the codegen to actually use it). The rest is just the benefit of 1000 small things that all add up to a greater whole.
PS, I used to enjoy your posts on SDN, before the site owner threw a fit. :-)
Phobos, the D standard library, makes C++ standard library look very small. C++14 standard library still can't do "ls", "execvp", "socket" in a portable way (but we finally got std::thread and std::function!). Phobos can do all of this, and also haves support for md5, gzip, diff, sort, getopt, json, xml, ...
Thus the need for an external library is a lot less likely than it is in C or C++, and you almost never spend time rewrapping native stuff: it's already done by Phobos.
And in the end, if you need to use some specialized library, D can call C and C++ functions with zero overhead (I have D projects that use CGAL and SDL).
And is we talk meta-programming, I think D goes further in the Stepanov style: https://www.youtube.com/watch?v=LIb3L4vKZ7U
It also compiles to native exes as the normal procedure. You can do that with Java / C# in special cases though.
D is much easier to pick up than Rust. Rust seems to take the runtime overhead of Java/C# and put it into your brain overhead during typing time.
D has very fast compile times, Rust has very slow compile times.
I should add that the GC actually works perfectly fine for normal work, it justs not up to the competition (Partly because of having to work with traditional dynamic memory).