Hacker News Reader

> While it's good to see the language evolving and improving, this type of churn also means it isn't very practical to use.

That's right. We never claimed otherwise.

> I keep hoping that it'll start to stabilize, even just on a feature set and standard library that may not be perfect, but will at least be usable for longer than a few months. Yet this doesn't seem to be happening. This lack of stability will start to significantly hurt its adoption at some point.

It is absolutely our intention to create a backwards-compatible version of Rust soon. We've created a milestone to tag issues related to this: https://github.com/mozilla/rust/issues?milestone=13&state=op...

> Go has taken a better approach, in my opinion. It isn't perfect, and it's lacking some important functionality, but at least there's a version that's usable, well-supported, and usable well into the future, even if the language does continue to evolve in incompatible ways.

Go also started earlier and is less ambitious of a language (and I think everyone on the Go team would agree with that statement). It has nothing like the borrow check that has required delicate care in design, and research in every sense of the word, to create something usable. Earlier versions of Rust were not really usable for what we want to use it for—Servo—and there is no point sticking to a language that isn't the language we need. Even current Rust is not ideal for Servo (lack of custom smart pointers, most notably) and that's why we continue to evolve it. Nevertheless, we have a good idea of the feature set we want and the language is stabilizing.

I agree. This is going to affect Rust's adoption if they aren't careful. People are hesitant to write tutorials, documentation, or code that may need to be rewritten later.

But I still give Rust a pass on this for the time being. Rust is a younger language than Go (Rust is not yet at version 1, while Go is at 1.1.1), and Rust supports far more compile-time features.

A little known fact is that Haskell's motto was to "Avoid Success At All Costs", i.e. that a long development cycle was incredibly valuable for a language. It takes a long time and much experimental use for features to settle into a good configuration. Rust will suffer from poor adoption for a long time if they wait on that. Rust will also be a better language for it.

When it comes to the Rust tutorials, documentation and code that do already exist, a lot of the information is now very misleading.

This may even be more harmful than no documentation at all, especially for people new to the language.

While this is an issue for other languages, I've found it to be far more severe with Rust.

Other languages went through a lot of change too. They just did it behind closed doors. We could have done our development behind closed doors too so you wouldn't see all the churn, but that's not the way we work at Mozilla.

Furthermore, Rust is quite ambitious. Getting lifetimes and the borrow check to work right is hard and involved research in all senses of the word; read the borrow check source code sometime. We did not just change things because we felt like it.

> Yet this doesn't seem to be happening.

Rust is starting to settle down, and once it has settled, it will be very stable. In particular, the 0.6 release was a huge breaking one, and 0.7 was less so. As it approaches 1.0, things should calm down quite a bit.

I just fear this "it must stop breaking things after 1.0" attitude some people have.

That's exactly what the death of a promising language looks like.

Those people should just go elsewhere, there are enough worse-is-better languages to pick from without dragging down yet another one.

I'm not sure that you're interpreting such a stance correctly.

Any further 1.x releases should clearly try to avoid incompatibility as much as possible. Anyone seriously using a programming language does require a relatively high degree of stability with respect to language changes, library changes, and so forth.

But that in no way means that there can't be work done on a 2.x release that does introduce incompatibilities in an effort to improve the language and any standard libraries it may offer.

This situation is much more about controlling change, rather than preventing it outright.

We have no interest in stabilizing Rust 0.5, 0.6, or any earlier version. They are versions of the language that are useless for our needs—they weren't even memory safe (and fixing that required breaking some code).

The most realistic way to address your criticism would just to have been to keep the language a secret until it's mostly stable. This is what most other companies do (for example, this is what Google did with Go). But then you couldn't use it at all.