Most Rust contributors are not Mozilla employees. Losing people to work on Rust full-time would be a setback, but we're not really reliant on it; we'd evolve more slowly.
https://dlang.org/blog/2017/05/31/project-highlight-excel-d/
Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they actually offer entirely different takes on programming. D, on the other hand, tried to fix problems that existed only due to the lack of work developing C++ beyond the 98 standard. Once the C++11 standardization process took off, D was pushed away into irrelevance.
We generally try to market Rust as a good language on its own merits rather than a "better X." That said, there are undoubtably comparisons to make, but the latest iteration of our marketing is "confident, productive systems programming."
After working with C++11 (or C++14 or C++17), D is such a breath of fresh air. Everything is so... easy. I can do what I want, and I don't have to worry about doing just the wrong kind of thing to get a segfault or UB. I might get stack traces at runtime if I make a mistake, or even better, compiler errors because my types didn't check correctly or my compile-time evaluations had errors, but the language is much simpler and cleaner because it's been able to throw out the baggage of C++. In fact, it's thrown it out twice, once for D1 and again for D2, what is now simply called "D".
And being able to actually throw out cruft without concerns for backwards compatibility is why D isn't irrelevant.
No doubt about it, many existing C++ users feel this way. I've read the same comment many times. Most programmers, however, are not C++ programmers, and they are not looking for a better C++. They are looking for the best programming language for their needs (which means in most cases they won't go anywhere near C++). Your comment about D being irrelevant doesn't make much sense.
And that's precisely why D fails. D was marketed as nothing more than C++'s successor, right down to the naming choice. No one is looking for a better C++, therefore no one bothers with D.
Meanwhile, those who have to work with C++ keep their eyes in the C++ standardization process. Since D's inception, the C++ standardization committee already produced three standards which oddly enough do include stuff that is sought after by the C++ community.
It's great that C++ is catching up. It's almost got static if, except not because it introduces a new scope. Maybe next time...
The C++ programmers I know are attached to native code, but not exactly content with C++. Ethan Watson of Remedy Games (Quantum Break) said "we are an industry looking for salvation".
The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting.
While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of being used for userspace "system" utilities in the same vein as the Rob Pike's C-like Alef on Plan 9). At the same time, much of the public rationale given for Go was obviously to avoid the pitfalls of using C++ at Google-like scales (e.g. an aversion to junior-dev footguns and a fanatical focus on fast compilation), which implies that they saw some potential for replacing C++, though they later acknowledged that very little of Go's growth appeared to be coming from C++ programmers (see https://commandcenter.blogspot.com/2012/06/less-is-exponenti... : "Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.").
Meanwhile, given that Mozilla intended to write a browser engine in Rust, old versions of Rust absolutely intended to replace C++. Like D and Go, ancient pre-0.1 Rust was willing to impose a runtime by default in order to guarantee memory safety (originally intending for both green threads and a garbage collector to be baked into the language), until years of experimentation proved that its static checks were capable of providing memory safety without a runtime, which is the pivotal moment in Rust history (actually a series of pivotal moments, but let me be romantic). Nowadays, rather than market itself as a C++ replacement exclusively, Rust tends to position itself outside of the traditional spectrum of languages as simply a zero-overhead memory-safe systems language. While it's still true Rust competes with C++, is inspired by C++, and can be used to replace C++ (e.g. its usage at Dropbox and in Firefox), Rust also intends to compete directly with C, e.g. for system utilities (e.g. ripgrep), reusable low-level libraries (e.g. librsvg), and extending high-level languages (e.g. Helix).
In any case, I will +1 you on coming from python and ruby, and add another major bucket go developers come from is node js.
Rob Pike uses the phrase within the first 5 minutes or so of the very first presentation video announcing Go, and explicitly mentions that they mean "systems" in the sense of webservers and the like. Since then, Go being a systems language has endlessly (and often maliciously) been misrepresented, so under these circumstances, it's only understandable why this phrase was dropped, even though it was absolutely appropriate since its first use gave plenty of context.
(I'm aware of Caddy, but my understanding is that it's aiming for ease of use over performance.)
is that true? Old versions of Rust looked like Go, IMO.
One interesting thing about D is that we don't have to answer to anybody, so nobody can kill D other than us. We just keep steadily pushing forward regardless.
Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities. Go is a ostensibly a "better C++" because it promotes higher-level, safer abstractions that are still "fast enough" (but not zero-overhead). Ditto Swift.
D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust. And I think that of all of these, Rust is the only one that can truly claim to be a "better C++" in a meaningful way. Others are "something better than C++ for most apps you'd write in C++ today".
As big C++ fan and language geek, I am pretty confident that if Java and .NET had taken the route of all other alternatives in the 90's (Oberon, Eiffel, Modula-3, Delphi,...), C and C++ would be less relevant today than they turned out to be.
This because many people make use of them, just because they are the only languages they know about compilers that produce AOT executables, with the option of static linking them.
Maybe even Longhorn would have been a success, instead of having to wait for UWP with .NET Native.
You probably won't be writing kernels with it.
So what, so do Oberon, Modula-3 and many others including D.
Yet quite a few production OSes were even written with them, e.g. Native Oberon for the Ceres Workstation at ETHZ.
Pauses weren't an issue for users' productivity.
http://www.ocp.inf.ethz.ch/wiki/Documentation/Front
Video editor playing a video on the lower right corner.
http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?...
Rust is the best bet we have at a better C (and a better low-level C++).
High level C++ competes with D and Go. Rust is a little too specifically targetted at the low level "systems" programming.
It is, to a degree a matter of taste, of course, but Go APIs tend to be rather simple, whereas Java libraries seem to often have FileOpenDialogStyleTemplateProcessorFactoryFactory-type interfaces.
The major problem I have with Go currently is lack of function overloading, which means you either have to convert your data around a lot or have many similar functions for different data types that do the same thing (basically), but have different names.
I think the comparison with Python is quite fitting, because both languages encourage a certain way to think about and implementing things. For Python it's called pythonic, in Go it's called idiomatic.
It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.
D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.
The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.
Pointers Gone Wild: Memory Safety and D http://dconf.org/2017/talks/bright.html
If not, then I would posit that it's not correct to say that it matches my definition.
The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.
http://www.mail-archive.com/digitalmars-d-learn@puremagic.co...
Not only is it not quite dead yet, it's growing rapidly : http://erdani.com/d/downloads.daily.png
DMD downloads direct from home page only.
If something is growing very quickly then saying it hasn't yet dethroned C, so it won't ever be significant seems to me to be a bit brittle thinking. Compound growth and the passage of time - thats what has been underway for some time now.
From what I have seen of D, it provides a C++ without some of the cruft, but without trying to solve other issues with C++-like languages (for eg: usefulness of Algebraic Data Types). Why should someone choose D today over Go or Rust for any project? I have yet to see a convincing answer.
Over Rust: No need to learn new concepts like borrowing
D over Go: D has much better language mechanisms for abstraction and programming in the large.
Go over D: Go has an incremental, mature GC.
Rust and D do not quite target the same application domains (though there's overlap), so it's difficult to compare them. Insofar as they do (D with @nogc and @safe), the tradeoffs become rather complicated.
It is usually only way some programmers are forced to adopt new programming languages, in spite they religious beliefs regarding how programming should be.
Notorious example, game developers moving from Assembly to C/Pascal and later from C to C++.
Or systems programmers being force to move into C++ instead staying with C (e.g. IO KIt and UMDF).