Breaking changes still happen, but commits to the rust repo are tagged with [breaking-change] so you can easily do a `git log --grep breaking-change` and (hopefully) get a good idea of how to fix your code. For more gradual breaking changes, the developers have been good at adding lints to rustc so you're told how to fix your code via compile-time warnings. Vec migration and crate attribute syntax are two recent examples of this.

It's worth mentioning that this policy is only a few weeks old, so it's more of a 'will be in the future' thing than it is 'all the changes so far' thing.

Not quite stable (current version is 0.10) but they are trying to keep the breaking changes to a minimum.

I wouldn't say "trying to keep breaking changes to a minimum"; breaking changes still happen a lot. More accurate would be that breaking changes are happening less frequently than they were and generally require less effort to accommodate.

Let's be a bit more precise: the _language_ has few breaking changes right now, but the _libraries_ are absolutely in a lot of flux.

My "Rust for Rubyists" doesn't use a ton of library code, and here's all it took from 0.9 to 0.10: https://github.com/steveklabnik/rust_for_rubyists/commit/9e5...

I looked through that, and it seemed that the vast majority of the changes were in prose, tool output, and println. There were some other smallish changes as well, but that doesn't seem so bad for a language that is being very clear that breaking changes are still occurring.

Yup. To be clear, this is a ~50 page introduction to the language, so it's not as though I'm testing all of the features of Rust, but the language itself is not changing a whole lot at this point. And what does is often a find/replace.