What does "really ready" mean when it comes to Rust?
That's the kind of vague goal that people will keep using as an excuse for not focusing on stability, and providing a product that's actually usable.
When it comes to programming languages, it's dangerous for their implementors to not produce something that's seriously usable as soon as possible, even if it means accepting some imperfections in the early stable versions.
With each passing day, Rust becomes closer to being something like Perl 6: anticipated, probably useful, but never actually "ready" enough to be usable. While I'm more optimistic about Rust potentially having a far brighter future than Perl 6, the lack of stability does cause unease.
Yes, sometimes the language/lib changes and you have to go through and edit all of your existing code. You can stick with point releases to minimize this, but most likely you won't want to, because these breaking changes fix problems and annoyances!
If you take a look at these changes for 0.10, they make progress on the language itself, and leaving these things as-is to stabilize the language would have been a terrible mistake. There are more of these in the line (DST..), as there should be. IMHO, Rust will be "ready" when such changes stop creating real progress.
Having watched Rust for several years now, it has always been apparent that it isn't an overnight language. Despite the goal of being based on only existing research, getting new implementations of ideas right takes careful deliberation. A large part of language design is getting the core features to play well with one another in ways that make sense, and creating well-thought-out core libraries that properly implement standard abstractions. Every inconsistency and incompleteness at this stage will lead to constant (poor) reinvention of these concepts to achieve the missing capabilities, and a subsequent proliferation of ecosystem glue code to make the different implementations communicate. A large part of why dynamic languages can be so expressive is that their core abstractions contain enough indirection to add missing functionality in a backwards-compatible manner, but a close-to-the-metal language simply does not have that luxury.
How does a non-static list of issues to resolve really help? The latest was added merely 4 days ago.
If anything, that's yet another way to justify not getting a stable release out there. It's the old "We can't release yet, still have bugs to fix!" trap that catches many software development teams.
There will always be some issues, so insisting on a vague notion of "perfection" becomes far more harmful than just getting at least something out there than users can actually use.
There will always be bugs: there are currently 1504 open issues on the repository. Those 48 represent the backwards incompatible changes that still need to be made. And 1.0 has 108 open issues in total.
That's the kind of vague goal that people will keep using as an excuse for not focusing on stability, and providing a product that's actually usable.
When it comes to programming languages, it's dangerous for their implementors to not produce something that's seriously usable as soon as possible, even if it means accepting some imperfections in the early stable versions.
With each passing day, Rust becomes closer to being something like Perl 6: anticipated, probably useful, but never actually "ready" enough to be usable. While I'm more optimistic about Rust potentially having a far brighter future than Perl 6, the lack of stability does cause unease.