> As mentioned above, I doubt that this is true within a year, but beyond that, any new language is also going to have all of these same growing pains, but be a decade behind. When they're ready, they should be considered, but "don't do a good thing now because maybe, some unknown amazing thing might appear" isn't usually a good way to make decisions.

This is true, but Linux is a long-term project, we don't know what the future will bring, but I'd be surprised if it wasn't still a mainstream kernel in 20 or even 40 years.

It seems to me it would be wise to look at the future as well, and perhaps things are the wrong way around; rather than asking "what existing languages could work for the kernel?" the question should be "what would the ideal language for the kernel look like?"

It always seemed to me that Rust is a bit of a strange choice for the Linux kernel; I can see why it has some appeal, but it's also a fairly large and complicated language.

How "complex" or "minimal" a language should be is an old debate that we've all done at least a few times, so don't want to repeat it here; for my part, I feel comfterable with both approaches; I'm just as happy programming in Ruby as in Go for example (even though they're polar opposites in many ways), but both approaches come with their own set of advantages and downsides.

I'm not so sure that a large and complex language is really the best fit for this particular purpose. For example writing a C compiler for a new architecture is comparatively easy whereas porting Rust to something new will be much harder.

Given Linux's long-term prospects it might be wise to invest in an "ideal" language rather than a "it'll work" language.

Then again, I don't work on Linux so what do I know :-)