A 1.0 release is wanted at the end of the year. Note: it will really only be stabilising the core language and an unspecified set of core libraries; it will likely take a while after that until there are stable libraries on a scale rivaling Python or Go.

I'm just hoping to avoid the level of instability that I've experienced in my Ruby projects over the years. It makes it nigh impossible to keep a project maintained sanely long-term as its dependencies evolve and even the language or stdlib change in backwards-incompatible ways every couple of years.

Not to dismiss the importance of language stability, but forward porting in Rust should be significantly easier than Ruby for a few reasons:

* Rust's strong type system means the pieces fit together only in specific ways - roughly, if you can get it to compile again it will work; in more dynamic languages you have little confidence that the code works until runtime.

* Co-evolving the language with the downstream community is such a critical issue that Rust is developing several tools and processes to help, and this should set it apart from other open source languages that have gone down this path:

The Rust process already attempts to tag all breaking changes in the commit log with `[breaking-change]` and we've heard anecdotally that this has made forward-porting Servo much easier. This log isn't published anywhere besides the commit log yet, but it will be.

Secondly, Rust has a [stability](http://doc.rust-lang.org/rust.html#stability) system that tracks API stability at a fine level. This is influenced by node.js, but in Rust stability is detected and use of unstable API's can be enforced by the tooling. This is still in development but you can see it in the [docs](http://doc.rust-lang.org/std/intrinsics/).

It's a fine line to walk. Don't change enough and you hemorrhage developers due to not supporting new and interesting features and concepts, change too much and you you hemorrhage developers who don't want to start a new project to run into the same problems as the last one, where an upgrade caused headaches. FWIW I think Rust's tagging of breaking changes (and eventually making them easy to identify and fix) as stated in a same level comment is wise no matter the strategy.

To give some concrete data about Rust's instability: https://gist.github.com/steveklabnik/616e89860446eb2a6732

I believe you've picked up some wisdom, congrats!

it will take at least a decade to rival Python. Go is a much, much easier target.

I doubt it will take that long to match what is considered the useful subset of Python libraries, if the language becomes popular.

What I've noticed from watching the Python, Ruby and Javascript module ecosystems approach and in some cases surpass CPAN (in terms of raw numbers of packages) is that there's a lot more programmers out there now, and a lot more existing implementations available in similar languages for just about anything you are attempting to do.

No one is aiming for all Python libs, just the standard libs (datetime,regex, etc.)

that looks like a 3-5 years affair, too. rust interests me greatly so i'll be really happy to be wrong.

1.0 is scheduled to be released by the end of 2014.