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....)
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?
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.
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.
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.
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.
(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....)