Linux Developers May Discuss Allowing Rust Code Within The Kernel

[discordian]

It would be a lot easier to discuss this if you told us what those reasons are.

Maintainers dont want to learn any other language (thats the primary one, symbol mangling would be an actual technical reason). It would be enough if they would use some features of C++ to lose some ugly macro magic.

Rust is particularly stupid for not following the dominant syntax type then name, but using something close but not similar to math statements.
ie.:
let i: u32 = "42".parse()

[szymon_g]

There was recently a discussion on allowing other languages than C for drivers. Something like that could make sense maintenance wise.

so... when will Python be allowed in?

[Templar82]

Rust to play a larger role at lower-levels of the system due to its memory safety guarantees and other security benefits.

What if we just wrote good C code instead?

[CommunityMember]

Well, they can discuss it but the answer will be very skewed toward nope, i simply can't see Linus accepting LLVM as a dependency because honestly LLVM is a can of worms on its own and very far still from "stable" for something that low level.

Some of the biggest (in terms of shipped numbers) vendors uses LLVM for their kernel. Historically there have been a number of gcc-isms that have entered the kernel (which was itself badness), but at this point the gcc-isms have been eliminated, and various test infrastructure prevents new ones from getting into the kernel.

And more than once LLVM compiled code correctly that GCC failed miserable on. All compilers have specific issues, but what, exactly, are the issues in your alleged can?

[CommunityMember]

I hope this will motivate gcc (and others) to start a rust frontend.

Either they will choose to step up, or step away. I will respect either choice they make moving forward (both have good arguments to support them).

[CommunityMember]

Niiice. I mean, small steps and everything, we wouldn't want to mess anything up, but adding Rust to the mix is a win imho.

There are issues with rust, and not being a "stable" language is but one (which is one of the gcc teams arguments). There are ways to address some of the issues (pick a rust dialect for the kernel?) but a valid question would be how to deal with such language changes. Even moving from gcc 3.2 to 4.8 was controversial in some circles (4.8 to 4.9 is less controversial, but that is mostly due to the minor uptick).

I like rust, but the supporting infrastructure and rapid changes/developments can be a real PITA to manage for anything beyond trivial examples.

Personally, I see this as one of those "it is going to keep coming back" proposals that while it may (or may not) be rejected this time, it will eventually pass muster. Perhaps it is just time to accept the baby steps are going to happen, whether or not everyone agrees.

[CommunityMember]

What if we just wrote good C code instead?

That might be ideal. But do you trust that 100% of the developers in your organization write good code? I am unaware of any org that has that level of quality assurance. And all it takes is one (kernel) developer to ruin your entire day (or week, or year).

[tildearrow]

Maintainers dont want to learn any other language (thats the primary one, symbol mangling would be an actual technical reason). It would be enough if they would use some features of C++ to lose some ugly macro magic.

Rust is particularly stupid for not following the dominant syntax type then name, but using something close but not similar to math statements.
ie.:
let i: u32 = "42".parse()

Every time I see "let" I just feel like going back to BASIC....

Rust: a language that looks "super cool" and "oh hey look exa/ripgrep has COLOOORRRZZZZ!!1!! alacrittyyyy AAAAA!!!" but then you look inside and is super hard to maintain

[bug77]

What if we just wrote good C code instead?

We're still waiting for the answer to that one for almost half a century now. Can't be much longer, can it?

There are issues with rust, and not being a "stable" language is but one (which is one of the gcc teams arguments). There are ways to address some of the issues (pick a rust dialect for the kernel?) but a valid question would be how to deal with such language changes. Even moving from gcc 3.2 to 4.8 was controversial in some circles (4.8 to 4.9 is less controversial, but that is mostly due to the minor uptick).

I like rust, but the supporting infrastructure and rapid changes/developments can be a real PITA to manage for anything beyond trivial examples.

Personally, I see this as one of those "it is going to keep coming back" proposals that while it may (or may not) be rejected this time, it will eventually pass muster. Perhaps it is just time to accept the baby steps are going to happen, whether or not everyone agrees.

It's been suggested above: use it for drivers at first. Drivers are more likely to wreak havoc, Windows has become more stable only after Microsoft cracked down on drivers.

I mean sure, you can find flaws in Rust (just like any other language), but the borrow checker alone ensures your code does what you think it does. That's a worthy addition to me.

[jacob]

Well C++ isn't in the kernel for a number of different reasons. Those same reasons are pretty much going to apply to Rust too.

Not really. C++ isn't in the kernel because Linus said it could only get there over his dead body. To my knowledge he has no principled objections against Rust.