There are already versions of OpenEmbedded leenucks that can't be built (whole system distributions, not the kernel.) To repair that you have to do A LOT of work rebuilding recipies, guessing which patches were included in various source bases.
And now we're going to have to maintain version closures for multiple editions of rust (unless there's a fiat indicating leenucks use is fixed at a particular edition.)
I like Rust. But the last time I used it extensively was around 0.8 and I just don't have the energy to keep learning new editions every couple years. And after surviving the Python 2.3 -> 2.5 -> 2.7 transitions, changing your syntax every couple years just sort of makes me want to curl up in a little ball and cry myself to sleep.
Seriously. I would rather keep coding in C. I hate C. Okay, maybe I just have a mild dislike for C. But I have non-trivial C programs I wrote in 1982 that still compile and run. I have one or two Rust programs from 5 years ago that don't compile and a whole bunch of Rust code from 10 years ago that flat-out doesn't compile.
I dunno. Backwards compatibility is a thing for me.
Linux use is fixed to a specific version of Rust, not just an edition.
Rust today is very different from Rust 0.8. And the changes in the last few years have generally been small and in targeted areas that need work. It's nothing like Python in the old days.
Backwards compatibility is a thing for Rust as well. Almost all old code in existence works without modification in newer Rust. (The breaking changes are mostly soundness bugs, and possibly some type inference.)
But of course Linux kernel is fixed to a specific version of Rust. It needs unstable features [0]. Changing the version may break. Which reinforces dingosity's point about the language:
> (Rust) needs to stabilize before it's used for critical infrastructure.
+ A particular version of the Rust toolchain is required. Newer versions may or may not work because the kernel depends on some unstable Rust features, for the moment.
They decided it was good enough. It will be locked in for some time. Mainline Rust development will be separate but related to Linux Kernel Rust development. It will be like using TinyGo instead of Golang because you're doing WebAssembly or embedded.
There are already versions of OpenEmbedded leenucks that can't be built (whole system distributions, not the kernel.) To repair that you have to do A LOT of work rebuilding recipies, guessing which patches were included in various source bases.
And now we're going to have to maintain version closures for multiple editions of rust (unless there's a fiat indicating leenucks use is fixed at a particular edition.)
I like Rust. But the last time I used it extensively was around 0.8 and I just don't have the energy to keep learning new editions every couple years. And after surviving the Python 2.3 -> 2.5 -> 2.7 transitions, changing your syntax every couple years just sort of makes me want to curl up in a little ball and cry myself to sleep.
Seriously. I would rather keep coding in C. I hate C. Okay, maybe I just have a mild dislike for C. But I have non-trivial C programs I wrote in 1982 that still compile and run. I have one or two Rust programs from 5 years ago that don't compile and a whole bunch of Rust code from 10 years ago that flat-out doesn't compile.
I dunno. Backwards compatibility is a thing for me.