I didn't decide the deadline, I ain't a Rust dev. :P If anything I would have wanted the deadline to be January 20th, to mark the three-year anniversary of Rust 0.1.

But in an attempt to answer your question, I see Rust development as an application of simulated annealing (https://en.wikipedia.org/wiki/Simulated_annealing). In all honesty, we could probably spend another two years toying around and seeking a "more optimal" solution... but I personally agree with the devs that we have reached a point where the value of seeking backwards-incompatible solutions no longer justifies the time spent unable to cultivate a growing stable of third-party libraries.

That said, Rust won't be standing still post-1.0. Not even close. There are lots of language improvements that will be arriving backwards-compatibly in the coming year (e.g. improvements to dynamically-sized types, improvements to closure type inference, various improvements to the trait system like negative bounds, and so on.). Longer-term, I expect Rust to look into a design for higher-kinded types, which could eventually allow for generic monads in the vein of Haskell (though this should be considered a very far-future goal, perhaps even worthy of a Rust 2.0).

I think it's worth noting that 1.0 is a stable release, meaning that any 1.x future release will not introduce breaking changes. But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0.

That allows them to tell people that, yes, they can depend on the fact that the language and API will not change from, say, 1.2 to 1.3. And that they will continue to support it for the foreseeable future. But I imagine that eventually they will want to make breaking changes, as they certainly won't get everything completely right with 1.0. But that will be clearly marked as an entirely new version.

Except the std lib isn't going stable for 1.0. They have a system that marks which APIs are stable, but a lot of stuff is still unstable/experimental. So it's very possible to write a Rust 1.0 program that won't work on 1.x, if you used those parts if the stdlib. Fortunately, the compiler can warn you of this so you know what you're getting into.

The plan is to have those unstable parts disabled in the stable compiler, so that any program that works with rustc 1.0 will work with rustc 1.x etc. One can use those parts via the nightly branch. The plan is also to try to have much of the most useful parts of the stdlib stable (at least the core functionality).

More info:

- https://github.com/rust-lang/rfcs/pull/507

- http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

> But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0.

Which lets us relive the fun times of eg. Dlang 2.0 release or Py3k

I can't think of a popular language which has not had breaking releases. C, C++ and Java all have.

The 1.0 stable release will be pushed back as far as is deemed necessary. Ideally it will be in 14 weeks, but if there's still critical work to be done when we hit that point, we'll wait another 6 weeks. And another. And another. We're not just going to push out whatever we have.

This is becoming very problematic for those of us who want to use Rust, but who aren't in a position to be constantly updating code we wrote last week so that it works with whatever changes were made to Rust this week. We really, really, really NEED a stable release of Rust. Earlier in 2014 we were hearing that we'd have it by the end of 2014. Earlier this month we were hearing that we'd have it by the end of March 2015. Now we hear it may be much later than that. It's not at all encouraging!

And end up with bad design choices for the sake of speed? No thanks. I'd rather wait as long as needed to perfect the design. Rust won't succeed unless its benefits over C++ are dramatic, obvious, and uncontroversial. I'm fine using C++ for a few more years if it means Rust will be amazing and not just OK.

The team is 100% focused on getting 1.0 out; I've been in the meetings, I've been sitting next to other core devs: they are putting their heart and soul into making sure 1.0 is soon and is high-quality.

Pushing it out before we think it is ready just because some people want to use it will result in stabilising a suboptimal language and so trade-off the long-term experience for the 5 years (or 5 decades?) for some short-term gratification.

The date for the alpha is hard, but the final release of 1.0 is not. That seems like a good compromise.