Google Wants To See Rust Code In The Linux Kernel, Contracts The Main Developer

[moltonel]

I really don't know why some Rust people are so against a GCC frontend. I see only positives in GCC-RS.

There are only positives to adding gcc as a backend for rust (main one is getting support for more platforms). The question is whether it's better to get there by writing a new frontend to be upstreamed in the gcc codebase (the gcc-rs approach) or by using the gcc backend library from the existing rustc frontend (the rustc_codegen_gcc approach).

The big issue with the "new frontend" approach is that it's a complex, never-ending project. It'll forever be playing catch-up with rustc in terms of features. It'll have a different set of bugs than rustc. It'll have a slower release cadence. It'll be an added burden for crate authors who are asked to support it. Not of these issues come up with the "new backend" approach : it's a simpler project, that can get feature-complete and enter maintenance mode. It provides the exact same portability benefits and doesn't risk splitting the ecosystem.

IMHO the reasons for gccrs are more political/emotional than technical/pragmatic. For example a preference for GPL over MIT. Or the dogma that having multiple frontends will always be good for the language (it was true in the pre-FOSS pre-Github world of C/C++/Javascript, but it's unlikely nowadays). Or the sectarian "LLVM is bad" reactions (forgetting that rustc isn't tied to LLVM). Or the fact that it's more fun and ego-boosting to write a new frontend than connect an existing frontend to an existing backend.

[Quackdoc]

They have to, No one wants to learn C anymore, not when rust is a thing. im not sure about the preformance benefits or detriments. but if it leads to a better safer kernel, im all for it,

[moltonel]

I don't know if it's some code inlined by the compiler or if it's in the standard library.

It's a library thing.

It also doesn't matter (except for the person fixing it), because I don't think it can be catched.

It can be caught, but that wouldn't be a good strategy for kernel code.

Linus made it pretty clear this is a big problem and THE biggest showstopper for integrating Rust, so it is very unlikely there is a simple solution like "we can just catch it and handle the error then".

The solutions are not trivial, but they are well known and are desired in other contexts, not just for Linux. Things like replacing the memory allocator, or completely removing APIs like infaillible accessors and unprotected float intrinsincs. But it's silly for you and I to second-guess these very technical details : you can trust that the kernel devs are looking very critically at the potential rust support and will only merge it if/when all fundamental issues are solved.

[jacob]

Pure speculation here, but if Google is so impatient, it almost sounds like they already have some substantial kernel code written in Rust that they can't wait to get mainlined.

[ultimA]

They have to, No one wants to learn C anymore, not when rust is a thing. im not sure about the preformance benefits or detriments. but if it leads to a better safer kernel, im all for it,

I don't get why people are still comparing Rust to C. If anything, it should be compared to C++. And with modern C++ (post C++11), C++ is just as memory-safe as Rust as long as you follow best-practice.

The real problem with C++ is that most of its modern safety features are opt-in, so to say. Rust wins because there they are opt-out. This makes Rust easier to teach and easier to learn. Rust really makes you have to go out of your way to write unsafe code. But it isn't that difficult in modern C++ either (you need C++11 or preferably newer), and those who claim C++ has much worse memory guarantees are those who never learned to use the modern features or its standard library correctly. In fact, I will make a bold statement: Anybody who is writing unsafe C++ today is either just simply a bad C++ programmer, or is being forced to use an old version of the language for historical/tooling reasons. Also, C++ was taught the wrong way for a very long time for modern standards, and there is still a lot of outdated experience going around. This gives wind to many rumors such as "C++ is memory-unsafe", which is not true anymore (as long as you make proper use of the newer features).

Then, there is the built-in synchronization checking and threading support with Rust. Yes, it is useful. Except in systems programming or the kernel context (like the Linux kernel), where you cannot use these capabilities.

[ZeroPointEnergy]

I kinda want to like Rust. But when even small projects suck in 50 dependencies for all over the place to build, I kinda feel like that added security the language might have is already out of the window by opening a huge supply chain attack vector.

[Quackdoc]

I don't get why people are still comparing Rust to C. If anything, it should be compared to C++. And with modern C++ (post C++11), C++ is just as memory-safe as Rust as long as you follow best-practice.

The real problem with C++ is that most of its modern safety features are opt-in, so to say. Rust wins because there they are opt-out. This makes Rust easier to teach and easier to learn. Rust really makes you have to go out of your way to write unsafe code. But it isn't that difficult in modern C++ either (you need C++11 or preferably newer), and those who claim C++ has much worse memory guarantees are those who never learned to use the modern features or its standard library correctly. In fact, I will make a bold statement: Anybody who is writing unsafe C++ today is either just simply a bad C++ programmer, or is being forced to use an old version of the language for historical/tooling reasons. Also, C++ was taught the wrong way for a very long time for modern standards, and there is still a lot of outdated experience going around. This gives wind to many rumors such as "C++ is memory-unsafe", which is not true anymore (as long as you make proper use of the newer features).

Then, there is the built-in synchronization checking and threading support with Rust. Yes, it is useful. Except in systems programming or the kernel context (like the Linux kernel), where you cannot use these capabilities.

I couldn't say, I am no programmer, but I can say at the very least, from what I have heard, it seems to be able to do both jobs fairly competently, but again, that's just what I have heard

[ssokolow]

It is not really a question of people but a question of use-case. For kernel-development, it has been made pretty clear that Rust in its current form is very unsuitable because it sometimes crashes the caller (not due to a bug in Rust but as a desien-intent) instead of letting the error be handler by the caller. This is unacceptable in the kernel where you want to handle the error instead of generate an instant OS-crash. But I think there are people working on fixing this.

That's like saying C is unsuitable for kernel development because libc assumes it'll be running in userspace.

Rust's panic!() macro is analogous to the Linux kernel's panic() function and the standard library components which call it on allocation failure are ones you're going to want to swap out for kernelspace use anyway.

That's part of the whole project. To design a Rust equivalent to Linux's klibc.

[krzyzowiec]

While I'm not necessarily opposed to this per se, it does feel like the motivation for this is more geared towards Rust being the hot new thing, and some opinionated/unverified "best-practice" dogma rather than based in actual technical merits.

Rust is so much better than C that it’s ridiculous. Technically it’s on par with C++, but with a few better defaults like immutability, no inheritance, better package management/library support, etc.

C is just horrible compared to either one. It’s not its fault, but it’s a product of its time that was great then but desperately needs to be retired for the betterment of the entire software field.

[krzyzowiec]

Seems to be what people want: More languages. Instead of one language project, they want to have 200 projects each a different language or one project with multiple.

Of the handful of languages that might be suitable for writing a kernel, there are only two that matter: C++ and Rust. We already know what Linus thinks of C++, so that leaves Rust as a modern language that is fit to do the job.