It's not. Rust is being used for production systems by several companies, so it hardly counts as a "research language".
> Anyone trying to fix/debug things in the kernel now has to learn Rust.
Wrong again. If a driver for some SD card reader is written in Rust, then you won't come in contact with this if you're working on the IPv6 subsystem.
I don't know that Rust has ever been a research language in the first place, maybe they mean "in development", as in pre-stability?
The 2005-ish "one man side project" and "searching for its niche" phases do sound researchy.
Interesting quote: "Funny enough, the zero cost obsession really wasn't me. I was ok paying some runtime costs. We just got overrun by C++ folks :P"
I agree that there's a cost to introducing a new language to a codebase. On the other hand, there's a cost to being stuck with only C, which manifests as security vulnerabilities and high cognitive overhead for want of better abstractions. I believe the Linux maintainers are taking a sensible and conservative stance here in allowing use of Rust, but not allowing Linux to depend on it.
I would accept that. The idea that C++ code from ten years ago can't always interoperate with C++ code written today is indeed a problem, but I think it's a very different problem that you're running into if you're trying to use Rust applications and libraries built ten years ago.
> there's a cost to being stuck with only C, which manifests as security vulnerabilities and high cognitive overhead for want of better abstractions
There's also a cost with abstractions. People who use Rust thinking it has "zero-cost abstractions" should probably get help crossing the street as well.
> I believe the Linux maintainers are taking a sensible and conservative stance here in allowing use of Rust, but not allowing Linux to depend on it.
100% agreed. Rust may indeed be the future, but the only way we'll know for sure is if we try it.
Hardly any different.