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.
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".
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.
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.
Exactly.
We've been discussing stabilizing these kinds of low-level features: no_std is first up. We're not 100% sure inline asm is worth it, as you can always link directly to something that's just written in assembly, but we'll see.
