I think at this point Rust is the winner just because it's already overcome the incredible hurdles of being shipped in the Linux and Windows kernels themselves. In that regard, I doubt there's room for any more of these new systems languages now.
I have the intuition that rust can’t possibly be the winner, it really feels too crude regarding the way it manages lifetimes. It really feels like the clumsy grandparent of the language that will indeed solve those problems elegantly.
But we made do with C for how many years? OP's question isn't whether Rust is as good as systems languages will get, the question is whether any successor language stands a chance of being included in the kernels.
The bad ergonomics of C were never enough to get another language into the Linux kernel, it took a language that solves the number one class of security bugs. It's unclear that any successor to Rust will be able to show as clear a need.
I like your style of writing :) - I watched a bunch of youtubers use it to do various things and was impressed but really I just want them to have a website and a way to sign up for beta easily so I can play with it too.
Not sure what you mean by "traditional oop setups" and why anyone should care about it, that's more of an outdated design pattern and a bad choice of the past than a desired language feature.
That's not how I read OP's question. OP was wondering whether a lang besides Rust can be "the winner" (unqualified) given that Rust has already passed the hurdle of being included in the kernel. It didn't sound like at all like their question was limited to whether there's room for another lang in the kernel.
But isn't it worth spending a few years poking around before we lock ourselves into fifty more years of bad ergonomics, now that things have clearly reached the point where there's credible motion towards a C alternative?
Rust's lifetimes have a steep (un)learning curve, but once you know what you're doing, they're fine. Really. IMHO Rust has ergonomic problems around effects or generic numeric code, but not memory management.
AFAIK no silver bullet has been discovered yet that would be an improvement over Rust that doesn't have some other trade-off. Val's mutable value semantics is more local and limited. It "solves" the problem of ugly lifetime annotations by not supporting complex zero-cost lifetimes at all. That doesn't mean Val can't be successful — it can be easier to use by supporting simpler constructs and focusing less on zero-cost abstractions, like Swift, but its ideas aren't stop-the-presses for Rust.
We're already overdue for having a more modern, practical replacement for C. Waiting for a hypothetical better-than-Rust language will only mean staying with C for even longer.
Like what happened with Java. Once a language has accumulated enough popularity it’s extremely hard to depose it, due to network effects. The switching costs are enormous.
The role of Rust in the Linux kernel is so far extremely limited, it's more of an experiment than a production tool at the moment.
I don't think that the "window of opportunity" for another language in the kernel has closed. If anything, Rust has shown what would be the hurdles to overcome, so it may inform the next attempt if it happens.
And of course Linux is not the only kernel out there, and new kernels can also arise.
