Wait, I don't understand these version numbers. Wasn't the previous release 0.9? I was expecting the new release to be 1.0, or 0.91, or something like that. Maybe this is standard practice for all I know.
I, for one, hope there are many more minor releases before any 1.0 - as many as it takes, and then some. Given the rate of breaking changes and how awesome they turn out to be, I would really hate to see this extremely promising language get stuck with warts for the sake of expedience. By the time 2.0 is on the horizon, everyone will have gotten used to and even depend on them.
Unfortunately there /seem/ to be a lot of people holding back from using it until the language is stable.
If so, that virtually guarantees some regret after it becomes stable and new users flood in with new use cases that need breaking changes to address in an optimal manner.
Edit: Perhaps I was too subtle. If you think rust is something that may meet your needs in the future, you should do future-you a favor and start using it now when there is still time to remove warts in a backwards incompatible way.
That theme is exactly what makes me worry that the team will give in to pressure to make a 1.0 before it's really ready.
I can understand the desire for stability before wrapping your head around a new language (typestate..), but if you're interested in Rust then you either patiently watch from afar, or at some point you just jump in and live with the breaking changes.
Semver seems like a straightjacket at the discontinuity of 0.x->1.0 if you don't want to commit to significant velocity of major versions. Perhaps the thing to do is define a second pre-1.0 series at 0.99.x, where breaking changes are made deliberately and include a source rewriting tool where possible?
We are going to commit to backwards compatibility at 1.0, but many (not all) libraries will be unstable, and we can always add stuff to the language as long as it doesn't compromise backwards compatibility for existing code. All 1.0 means is "we're going to stop breaking your code, and we have a reasonable, stable platform on which a lot of useful software can be written".
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.
I've been learning a teeny tiny bit about C, for the low-level aspects. Rust seems much better (at least eventually), but I was afraid that it was so good that it spoil me and turn me off going back to studying C. But maybe this really is the best time to get into Rust - for Rust to get as an active community as possible. Even though increasing that community participation might only manifest itself as more newbie questions on IRC on my part. :)
Have no fear asking newbie questions on the IRC, we were all there once :). #rust also has a reputation for being quite friendly and welcoming to new folks.
Unfortunately Rust is not actually using semver, which I always found confusing because they seem to be in support of it, and they even include a semver library in the core distribution. If they were following semver, this release would be version 0.10.0 (notice the patch version).
The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
Right, we didn't really "adopt" semantic versioning until sometime after 0.1, and so we've never really gotten into the habit of including the patch revision (and with one exception, we've never issued a patch for any of our unstable releases anyway).
This is standard practice. The decimal points are generally dividers between major, minor, and patch numbers. Hence why it is not uncommon to see something with a version number like 2.1.4 or similar.
