Hacker News new | past | comments | ask | show | jobs | submit login

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.

Rust is usable today.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact