We have very strong backwards compatibility guarantees. We do reserve the right to make soundness fixes, but they must be trivial to fix in user code. Otherwise, we don't break backwards compatibility. We have had one or two of those in the first year and a half of post-1.0 Rust, but virtually all code that did not hit one of those issues still compiles today. Newer iterations of the C standard have also introduced small backwards incompatibilities, it's just how the world works.
Our intention is to have that kind of long-term stability, yes, and we put a lot of work into making sure that it happens.
I'm glad to hear that -- I've had bad experiences with some other languages moving too fast and breaking things. I understand that's great for people developing every day, but I have several systems I dip in and out of.
Now I know rust has entered a stable phase, I might give it a look!
These are the RFCs and policies we came up with when cutting 1.0. I haven't read them in a while, but there haven't been any changes. Some of the text and/or examples might be reflective of the time they're written.
Oh, and one more thing: we have a tool, "crater", that we run every so often against every open source package in the ecosystem to make sure things don't break. Some of the most popular packages are built on every commit, as well.
Is rust willing to make that commitment? Or even 5 years? 2?