On the nontechnical side I would add that since D is a lot older, keeping up with changes is a whole lot less challenging. Its stable enough that one can put it near the money without worrying too much about breaking changes.
My impression is that things are settling down now, but I've encountered quite a few rust code bases that required "latest rust" (latest > 1.0) - and even "nightly".
Not to say that rust-the-language hasn't stabilized, but I think the point about D being (way) more mature still stands?
(Note, it's a good thing that people are writing code to test/work with/exercise latest rust/nightly etc -- but just because I can be fairly sure code I write today will compile tomorrow (which is good!) -- that doesn't mean "all of rust land" is stable).
Please don't take this of critique of all the hard work going into rust -- the only way this wouldn't be a thing was if rust core was a dead project.
[ed: To add to that - it might well be that all of the projects I've seen lately where I've had to wake up multirust[1] and do a little dance before my beautiful random code from random person on the Internet have been willing to compile -- have all been bad samples of rust code - but they're still part of the landscape of rust code one encounters in the wild.
[1] https://github.com/brson/multirust (eats a bit of space (~200MB per version of the compiler/toolchain) - but in my very limited testing works nicely!)]
> quite a few rust code bases that required "latest rust" (latest > 1.0) - and even "nightly".
In my experience most of these either use old features which have a stable counterpart, or use compile-time codegen (there are stable libraries to do this now, though they aren't as ergonomic as plugging into the compiler directly)
Yeah, I mean, I don't take this as a critique, it's the same for basically every language. When you build a project with a new version, you might take advantage of the new features. Such is life. :)
GP is actually the second post in a week I've seen where someone mentions tracking rust changes, but rust has been 1.0 for a while now. Have there actually any backwards incompatible changes since 1.0, or are people really complaining about a problem that's been fixed for close to six months and even then was specific to beta versions?
There haven't been backwards-incompatible changes in practice, no.
That is to say: there have been technically backwards-incompatible changes, but every compiler and language, including those of C++ and Java, make technically backwards-incompatible changes in point releases (e.g. defining new functions in the libraries and modifying undefined behavior). Rust doesn't make changes that violate the stability guarantee. It goes further than that, in fact—any change that is not breaking according to the public guidelines but is thought possibly breaking in practice is tested against crates.io and feedback is solicited from those who have any private crates that might be affected to make sure it doesn't break them either.
(Unfortunately this policy is often misunderstood—for example, it's been claimed that Rust will make breaking changes as long as they don't break anything on crates.io, which is very much not an accurate description of it.)
Due to its erratic development and the much-delayed release of Rust 1.0, I fear that many people have associated Rust with frequent breaking changes, even if that is no longer the case. It's much like the "Java is slow" fallacy; it may have been true in Java's very early days, but it hasn't been the case for many, many years. Yet the misconception still persists, even to this day. This is the sort of taint that a language will find very hard to shake. The "Rust suffers from breaking changes" misconception is very ingrained in the minds of many programmers now.