> Since 1.0, Rust has in fact had multiple significant stable-breaking compiler changes, not to mention that, among other things, adding any new method to a trait or type in the standard library has the potential to cause breakage. The official code stability promise has not been violated by these changes only because it's riddled with exceptions.

This is essentially the same as any other language. Adding a new method to traits or types can also break JavaScript, the other example you gave.

In fact, I know of one such example where code was broken in the wild because of new methods being added, and we did not revert the change. Marijn Haverbeke's winning js1k entry relied on the 4th and 7th letters (or something along those lines) of every CanvasRenderingContext2D method being unique, because it compressed code by renaming the canvas methods with what was then a perfect hash function. A new Firefox version was released months later that added new methods and broke the code. That was deemed an acceptable piece of breakage, and Rust's policies are very similar.

Anyway, the vast majority of breakage that we've seen so far was due to the libcpocalypse. This was an issue with people not specifying specific versions of libraries they depended on, not the language.

Here's another example with less trivial breakage, which was reverted:

https://www.fxsitecompat.com/en-US/docs/2015/string-prototyp...

Unless you mean to refute the idea that JS doesn't break anything ever - which it clearly does, occasionally, but proof-of-concept golf code that intentionally takes fragile shortcuts isn't the best example.

...But JS has moved away from monkey patching builtin objects for good reason, whereas Rust tends to be relatively promiscuous in adding methods to other people's types via trait impls. This isn't bad per se, but I do think it creates bigger compatibility risks.

I don't think this phrasing is particularly charitable, yet we don't need to argue about semantics, because we have numbers.

  > Approximately 96% of published crate revisions that build with the 1.0 compiler 
  > build with the 1.5 compiler.

https://internals.rust-lang.org/t/rust-regressions-2015-year...

I've seen it, and if that rate of 4% of code breaking in half a year were to continue, in the above stipulated 5 years it would look pretty bad. Hopefully it will not, given that some of those regressions involved soundness issues and other things (integer fallback) that were "clearly wrong", which ought to be mostly weeded out before long. That said, the rate of new features in the language and especially libraries seems likely to increase a bit in the nearish features, given the size of the feature request backlog (or not - you'd know better than I).

But even at a rate of significantly less than 4%, there's still trouble. That figure is based on the number of root regressions, right? (If I'm wrong, disregard the rest of this paragraph, but I don't think so...) That is, the number of crates that break on their own accord, rather than those that won't compile because one of their dependencies is broken. If one application depends on dozens of crates (or is just really large), the chances of it breaking somewhere are much higher.

This can be partially mitigated by the crates themselves releasing upgrades, but look at Python 3 - there will eventually be a lot of code out there that's completely unmaintained, especially within the "dark matter" of internal or closed source applications. Also, a fix in the latest version of a crate will probably not be backported to long deprecated major versions of it - which means that if I dust off a crate that hasn't been touched in years and uses such a version, I'd have to either upgrade the dependency or do the backport manually.

And the ancestor post did say five years: last I checked on the lists, there was no real consensus as to when Rust 2.0 should be released, on a scale from "in a year" to "never". Maybe there is more consensus internally, but I'd be surprised if it didn't happen in that long...

edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.

I'm convinced that the breakage in new C++ compilers is worse than Rust's breakage. New C++ compilers and language revisions break more than 4% of code. Likewise with many other languages, such as Ruby. We're just very up front about regressions when they do occur.

> edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.

As a matter of fact, JS's stability promise is very similar. See my other post for an example in which JS was broken due to, essentially, one of the reasons you cited, and we lived with it. The JS stability promise is not "we will never break any JavaScript in theory with new browser versions", because that would prevent anyone from, as an extreme example, changing the sorting algorithm for Array.sort. It's "we will not break you in practice, except in a carefully delineated set of circumstances." (Actually, JS's stability promise is much weaker than that: its stability in practice is decided by browser consensus and market forces rather than a clear set of rules.)

You're correct about impacts of popular crates, this is why crater is so important. A nice benefit is that popular crates should also have more attention on them, since they're popular, so if they are hit by a soundness issue, it should be addressed quickly.

The core team feelings on a 2.0 is much closer to the "never" end of the spectrum than the "in a year" side.