Linux Developers May Discuss Allowing Rust Code Within The Kernel

[Marc Driftmeyer]

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).

Do you think a single kernel code developer gets passed Linus's scrutiny over their code w/o being highly competent and efficient? Seriously, take a look at his history. He's a taskmaster about coding standards. It's quite standard if you have worked around and know kernel developers. My own experience at NeXT Inc and Apple made it clear they are an elite group of developers.

[Marc Driftmeyer]

I saw the comments of "write good C code" but the whole point of Rust is that even with great coders, eventually your code will do something with memory that you never expected. If you hate seeing memory errors then maybe you'd like to hear what they have to say.

Also, the Rust compiler is amazing.

The Rust compiler like all compilers is written by humans, thus the idea of `amazing' is relative. Fifty years of C Programming development and being the foundation language all these other languages draw from speaks for itself and why every major OS Vendor kernels are written in C.

[jacob]

The Rust compiler like all compilers is written by humans, thus the idea of `amazing' is relative. Fifty years of C Programming development and being the foundation language all these other languages draw from speaks for itself and why every major OS Vendor kernels are written in C.

Virtually all real world kernels are written in C because for decades it has been more or less the ONLY language usable for that task. It does not mean that C is a particularly GOOD language for that task (in fact, we have mountains of evidence that it isn't).

[HadrienG]

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()

Type-then-name is a bad idea.

• Without a variable declaration marker keyword like "let", you get a parser ambiguity (is this line of code a variable declaration or not?).
• If you tried to fix this with some kind of "let type var = value" syntax, you still couldn't introduce type inference without adding another parser ambiguity.
• C's universally reviled function pointer syntax and C++'s most vexing parse show that type-then-name isn't as intuitive as it is sometimes lauded to be.

Being easy to parse by something that's not a compiler is something that sounds like an unimportant programming language property until you try to develop programming language tooling which is not a compiler (syntax highlighting, documentation generators, static analyzers, etc).

[curfew]

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

I believe Linus once said that so many C++ programmers produce such god-awful code that if banning C++ language from Linux codebase keeps them away, that reason alone is good enough to justify his position.

[llukas]

Type-then-name is a bad idea.

• Without a variable declaration marker keyword like "let", you get a parser ambiguity (is this line of code a variable declaration or not?).
• If you tried to fix this with some kind of "let type var = value" syntax, you still couldn't introduce type inference without adding another parser ambiguity.
• C's universally reviled function pointer syntax and C++'s most vexing parse show that type-then-name isn't as intuitive as it is sometimes lauded to be.

Being easy to parse by something that's not a compiler is something that sounds like an unimportant programming language property until you try to develop programming language tooling which is not a compiler (syntax highlighting, documentation generators, static analyzers, etc).

does most vexing parse still occurs with auto?

[HadrienG]

I am wondering why not ada? It is more robust and readable than rust.

Having personally taken a look at Ada kernel development before, there are a number of problematic things there:

• Some language features (e.g. exceptions, variable-sized returns, multitasking features...) have heavy runtime requirements. So a bit like with C++, you need to learn, through much poorly documented guesswork, what subset of the language is usable on the bare metal and what isn't. Except it's worse in the Ada case because there are more such features. This is handled better in Rust, where most of the features that require runtime support are standard library features, not language features, as in C. The biggest exception AFAIK is panics, and even there the fact that `panic = abort` is a well-accepted language operating mode and not something that requires fiddling with weird compiler flags is a nice touch.
• There is only one Ada compiler that is not in maintenance mode, and its economic model means that unless you have a lot of money to spend, you will only get compiler updates once a year. Waiting a year for a compiler bugfix to be released is no fun.
• Because of this de facto GNAT monopoly and the generally low popularity of Ada OSdeving, little effort has been expended into properly documenting and standardizing the language implementation aspects that one needs to interface with when operating at the bare metal. Basically you need to dive into the source code of the GNAT runtime, which isn't terribly pleasant to read, and hope that you will eventually make sense of it.

It's not impossible to work around these things, as evidenced by the fact that there are a number of kernels written in Ada out there. But it definitely feels less at home than in C or in Rust.

[HadrienG]

does most vexing parse still occurs with auto?

auto's type deduction is limited, and assumes that the compiler will have enough context to figure out the right variable type from the right hand side of a variable declaration alone. It breaks down in more complex cases, such as when you declare a variable without initializing it right away (as is common with arrays), or more generally when a variable's type is defined by how this variable is used later on (very convenient, but basically impossible to support in a language with function overloading).

[ssokolow]

I don't understand your objection.... I really like the `name:type`syntax, as this enables type inference (`let v = "hello world"`) and prevents namespace collisions between types and variable names. `"42".parse()` feels very natural coming from an OO background (which is the dominant form of programming).

...and, if you don't like methods, they're just syntactic sugar.

let i: u32 = "42".parse().unwrap(); is syntactic sugar for the equally valid let i: u32 = str:arse("42").unwrap(); or let i = str:arse::<u32>("42").unwrap();

(parse() takes advantage of one of the few ways Rust allows for method overloading so, if you don't specify a type on the variable, you need to use the ::<> "turbofish" operator to disambiguate what type you want it to return... and yes, there has been a lot of discussion surrounding the turbofish. It's agreed to be the best of a bunch of bad options with the only more elegant solution being to not use <> for denoting generic type parameters. Rust devs are big on managing parsing complexity.)

...and if anyone knows how to disable emoticon conversion for inline monospaced text under vBulletin, please let me know.

[starshipeleven]

What if we just wrote good C code instead?

mistakes happen. If the language straight does not allow some types of mistakes, they won't.