Earlier quoted context omitted.
>For people who have to stay on top of language changes (not everyone) Or anyone that wants to try out the latest "$something but in rust" and tries to compile it. >who are on a wonky platform or that doesn't update quickly enough, ie, the vast majority of people so I question the word "wonky" here. >This may have once been true, but isn't really anymore. It's still true in my experience. But then again, Rust does ch…
> Or anyone that wants to try out the latest "$something but in rust" and tries to compile it. This is kinda true. I think a smallish demo re: who usually downloads a compiler, but it happens. I had a very sophisticated user/dev file a bug about how my software wouldn't compile. Turns out re: compiling from source they downloaded an old version of rustc from their distro's repos, instead of following my instructions,…
Bash gets new features, forwards incompatible features, fairly regularly still. It changes almost as much as Rust. But guess what? Bash devs don't expect that it's only other Bash devs using the latest bleeding edge version from last month. They, in general, write code that will work anywhere any time.
Rust code could be written in this way. But it it isn't because of the type of demographic that current writes in Rust. I have confidence this will change over the next decade. But right now, fast forwards incompatible changes combined with fast forwards incompatible devs makes for a very limited lifespan of any rustc. And that leads to the vast majority of the documentation suggesting curl | sh. You don't get that with other languages.
I'm not arguing for no change ever. That's silly. I'm arguing for not writing for the bleeding edge just because you can.