I&#x27;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 &quot;clearly wrong&quot;, 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 <i>increase</i> a bit in the nearish features, given the size of the feature request backlog (or not - you&#x27;d know better than I).<p>But even at a rate of significantly less than 4%, there&#x27;s still trouble.  That figure is based on the number of <i>root</i> regressions, right?  (If I&#x27;m wrong, disregard the rest of this paragraph, but I don&#x27;t think so...)  That is, the number of crates that break on their own accord, rather than those that won&#x27;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.<p>This can be partially mitigated by the crates themselves releasing upgrades, but look at Python 3 - there will eventually be a <i>lot</i> of code out there that&#x27;s completely unmaintained, especially within the &quot;dark matter&quot; 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&#x27;t been touched in years and uses such a version, I&#x27;d have to either upgrade the dependency or do the backport manually.<p>And the ancestor post did say <i>five</i> 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 &quot;in a year&quot; to &quot;never&quot;.  Maybe there is more consensus internally, but I&#x27;d be surprised if it didn&#x27;t happen in that long...<p>edit: It&#x27;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&#x27;s <i>other</i> programming language.