[spoiler]

cc: @foogered

This is what's been so off-putting about Rust, to be honest.

"I should never assume" is precisely what bothered me.

I loved Rust at first, but it required so much maintenance with its constant changes between versions, that I stated to dislike it. I didn't have much time (and I enjoy learning new languages), but when I had to virtually unlearn something just learned the previous day, it became frustrating after a few iterations.

A colleague at work once sneered at me when I suggested I could do my next [internal] project in Rust; I didn't end up using Rust, because I got self-conscious about the idea, and kinda got scared that I'll have to do much, much more work simply because completely valid code would not work in a few days. That feeling is kinda stuck with me to this very day, even though Rust wasn't a stable release back then, and now is.

Not to mention, there's people I've talked to about Rust who still feel like Rust isn't mature and never will be—simply because of it's "reputation."

[1]: They were referring to how dramatically and chaotically it changed before the first stable release.

[pcwalton]

What would you preferred Rust have done to avoid this "reputation"?

I mean, as far as I can see, the options were "develop Rust in secret" or "make a language much less suited to this domain".

[mcguire]

It's kinda bad, but the other options are worse. What're ya gonna do?

(Now, could we do something about the fair-sized chunks of the standard library that are marked "unstable"? I'd be happy with a compiler flag to turn that error into a warning....)

[heinrich5991]

There is an option, use the nightly compiler.

[plesner]

I wonder how many of the features in Rust that have changed were designed with that possibility in mind? And if not, whether it would have made any difference if they had been?

[steveklabnik]

As a very drastic example, the runtime was only actually removed six months ago. If we still had it, our 'embedding Rust in other languages' story would be significantly worse, and the kinds of things being discussed in this thread wouldn't have been possible.

[pcwalton]

The goals of Rust have not really changed since its development.

The fact is that (in particular) a region and lifetime system are hard. We were doing research. Research usually requires many attempts to solve a problem.

[plesner]

That's exactly why I ask.

It feels like languages often struggle with compatibility issues down the road because they assume that they're making all the right decisions from day one. Since you guys are aware that getting this stuff right takes many attempts maybe it would factor in the design process of a new Rust feature that it might eventually be replaced? I can understand if it isn't though, it's another constraint on problems that are already very hard.

[Jweb_Guru]

Many times during Rust's design process, I saw quotes like this:

"Rust is not the first systems language and will not be the last."

and

"Rust is a language designed for the hardware of today, not that of ten years from now."

Rust is just a stepping stone on the path to better systems languages. It's not the greatest language ever and it made mistakes, but it gets enough right to make it a very compelling option in the systems programming space.

[klibertp]

Why would you expect stability from software in early alphas is beyond me. If you want to be an early adopter you need to take the maintenance problems into account. And if you just wish to use a somewhat completed language you should have just waited for a final release.

PLs are complicated beasts and developing them takes time. It's normal for a language to change drastically during development: frequently it turns out that some feature doesn't fit well with some other, and you need to scratch the feature or redesign both features.

[geofft]

For what it's worth, inline assembly has been available in Rust ~forever, it's just not in Rust 1.0, the stable release, so a lot of people missed the existence features like this.

On the flip side, Rust 1.0 doesn't have any of the problems you describe. Rust 1.0 code will work just fine in Rust 1.300 when it comes out in 2050, provided that the language is still around. And inline assembly will end up in a stable release as soon as that promise can be made about it.

[mathetic]

>> They were referring to how dramatically and chaotically it changed before the first stable release.

Exactly.