I'm not even sure what the argument is here. DeVault's actual argument begins with: Yet, in the subsequent paragraphs, this is poorly argued. Indeed, I would say that Rust's better handling of...
I'm not even sure what the argument is here. DeVault's actual argument begins with:
One could espouse about Cargo, generics, whatever, but these concerns matter relatively little to kernel hackers.
Yet, in the subsequent paragraphs, this is poorly argued. Indeed, I would say that Rust's better handling of enums and unions is sufficient to prove its superiority to C for kernel work on general, though I agree that just being incrementally better than C is not enough to be included in the world's most convoluted C codebase.
The question then becomes: what advantages can Rust bring to the kernel? Based on what I’ve seen, these essentially break down to two points:
Memory safety
Trendiness
This is just straight up bullshit, because he's now arguing against his own point in the previously quoted span. Obviously "Cargo, generics, whatever" (in fact, ADTs, better stack unwinding support, more explicit intmath handling, and yes, very powerful generics) are worth it to at least some kernel hackers, including Linus, so why is "trendiness" the only thing he can think of other than memory safety?
DeVault's first paragraph was correct:
I am known to be a bit of a polemic when it comes to Rust. I will be forthright with the fact that I don’t particularly care for Rust, and that my public criticisms of it might set up many readers with a reluctance to endure yet another Rust Hot Take from my blog.
This is an unserious post and unless you enjoy flamewars I suggest you skip it.
This quote is so funny to me. There are possibly some unspecified parts of Linux somewhere that are well-designed enough to not face memory safety issues? The idea that it's hard to name them and...
I will offer this quote from an unnamed kernel hacker, though:
There are possibly some well-designed and written parts which have not suffered a memory safety issue in many years. It’s insulting to present this as an improvement over what was achieved by those doing all this hard work.
This quote is so funny to me. There are possibly some unspecified parts of Linux somewhere that are well-designed enough to not face memory safety issues? The idea that it's hard to name them and that it took hard work is a big part of the problem. It doesn't take hard work to keep Rust code memory safe or to check if it is. New parts of the codebase can skip this hard work if they're written in Rust. It's also much easier to check if future changes to Rust code are safe than to check future changes to C code.
And then it's funny that this is all the text the article spends on talking about memory safety, and instead the article veers off into criticizing Rust's trendiness. He tries to paint Rust as a totally arbitrary language choice and fashion.
Programmers are very used to seeing debates about which programming languages are better than others, and I think some have mislearned the answer as that all languages (or all languages within a given category, like statically-typed languages without garbage collection) are equally good, only differ in arbitrary shallow ways (like which IDE and libraries you can use with it), and that people who care about the difference are just trying to impose their fashion on others. There are many languages that differ in relatively shallow ways (Java and C#; Python, Ruby, and arguably Javascript), but Rust genuinely brings important stuff to the table that other languages within its category (statically-typed languages without garbage collection: C, C++, etc) don't.
I am tired of seeing garbage collection touted as some kind of boogeyman. It is not! It solves important problems that don't really have better solutions, and it is not ill-suited to writing...
statically-typed languages without garbage collection
I am tired of seeing garbage collection touted as some kind of boogeyman. It is not! It solves important problems that don't really have better solutions, and it is not ill-suited to writing device drivers, schedulers, ...
That quote led me to think about that if anything those doing that hard work should feel even more proud! I mean, they've done something very difficult in achieving something that doesn't have...
That quote led me to think about that if anything those doing that hard work should feel even more proud! I mean, they've done something very difficult in achieving something that doesn't have "memory safety issues in many years". That someone else says "I can't do that consistently; so we built a tool that helps us reach a similar level of quality" should be taken as very high praise! But, of course can't control how others hear what you say :)
An important aspect of bringing Rust into existing codebases is it's also an opportunity to build with hindsight. At work we're adding Rust to an existing (esoteric) operating...
An important aspect of bringing Rust into existing codebases is it's also an opportunity to build with hindsight. At work we're adding Rust to an existing (esoteric) operating system/kernel/userspace environment. Even though Rust does not come out-of-the-box with fallibly allocated collections (so you can catch out of memory errors when expanding a vector for example) we can pull in an existing fallible collections library and build everything new with that. This isn't even a feature of rust, but because we can't as easily start using C++ vectors as we can a 3rd party fallible Rust vector, the safe Rust alternative will get used.
I think there genuinely was a bit of a language rut for a while, where most arguments were pure squabbles over different flavors of syntactic sugar. In web development it didn't matter much if your back-end was in C# vs. Java vs. Rails. But today you can have a full-stack Typescript app where you can finally have perfect code reuse between the front end and back end. I've heard a CEO I worked with say how "you can write a good app in any language" as an argument against building a new app in TS. There's truth to what he said, but he's been out of the coding game for a decade and might not realize the paradigm shift full-stack TS is.
Rust is similar. And the hype/trendiness is an argument in its favor! There's a large middle range between garbage tech and golden bullet solutions where self-fulfilling prophecy effects are worth as much as the tech itself. If people believe in Rust it's more likely to succeed.
Is this because you can still rely on the memory safety of third party Rust packages where you can't with C++?
This isn't even a feature of rust, but because we can't as easily start using C++ vectors as we can a 3rd party fallible Rust vector, the safe Rust alternative will get used.
Is this because you can still rely on the memory safety of third party Rust packages where you can't with C++?
Others have said most of my thoughts on this one already, but my biggest surprise here was learning that he's only 29 - from the handful of these blog posts (and associated controversies) I've...
Others have said most of my thoughts on this one already, but my biggest surprise here was learning that he's only 29 - from the handful of these blog posts (and associated controversies) I've seen I'd totally assumed he was a grumpy old hacker from the 80s!
I'm not even sure what the argument is here. DeVault's actual argument begins with:
Yet, in the subsequent paragraphs, this is poorly argued. Indeed, I would say that Rust's better handling of enums and unions is sufficient to prove its superiority to C for kernel work on general, though I agree that just being incrementally better than C is not enough to be included in the world's most convoluted C codebase.
This is just straight up bullshit, because he's now arguing against his own point in the previously quoted span. Obviously "Cargo, generics, whatever" (in fact, ADTs, better stack unwinding support, more explicit intmath handling, and yes, very powerful generics) are worth it to at least some kernel hackers, including Linus, so why is "trendiness" the only thing he can think of other than memory safety?
DeVault's first paragraph was correct:
This is an unserious post and unless you enjoy flamewars I suggest you skip it.
This quote is so funny to me. There are possibly some unspecified parts of Linux somewhere that are well-designed enough to not face memory safety issues? The idea that it's hard to name them and that it took hard work is a big part of the problem. It doesn't take hard work to keep Rust code memory safe or to check if it is. New parts of the codebase can skip this hard work if they're written in Rust. It's also much easier to check if future changes to Rust code are safe than to check future changes to C code.
And then it's funny that this is all the text the article spends on talking about memory safety, and instead the article veers off into criticizing Rust's trendiness. He tries to paint Rust as a totally arbitrary language choice and fashion.
Programmers are very used to seeing debates about which programming languages are better than others, and I think some have mislearned the answer as that all languages (or all languages within a given category, like statically-typed languages without garbage collection) are equally good, only differ in arbitrary shallow ways (like which IDE and libraries you can use with it), and that people who care about the difference are just trying to impose their fashion on others. There are many languages that differ in relatively shallow ways (Java and C#; Python, Ruby, and arguably Javascript), but Rust genuinely brings important stuff to the table that other languages within its category (statically-typed languages without garbage collection: C, C++, etc) don't.
I am tired of seeing garbage collection touted as some kind of boogeyman. It is not! It solves important problems that don't really have better solutions, and it is not ill-suited to writing device drivers, schedulers, ...
Can't you? Have you looked at all at the software ecosystem these days?
That quote led me to think about that if anything those doing that hard work should feel even more proud! I mean, they've done something very difficult in achieving something that doesn't have "memory safety issues in many years". That someone else says "I can't do that consistently; so we built a tool that helps us reach a similar level of quality" should be taken as very high praise! But, of course can't control how others hear what you say :)
An important aspect of bringing Rust into existing codebases is it's also an opportunity to build with hindsight. At work we're adding Rust to an existing (esoteric) operating system/kernel/userspace environment. Even though Rust does not come out-of-the-box with fallibly allocated collections (so you can catch out of memory errors when expanding a vector for example) we can pull in an existing fallible collections library and build everything new with that. This isn't even a feature of rust, but because we can't as easily start using C++ vectors as we can a 3rd party fallible Rust vector, the safe Rust alternative will get used.
I think there genuinely was a bit of a language rut for a while, where most arguments were pure squabbles over different flavors of syntactic sugar. In web development it didn't matter much if your back-end was in C# vs. Java vs. Rails. But today you can have a full-stack Typescript app where you can finally have perfect code reuse between the front end and back end. I've heard a CEO I worked with say how "you can write a good app in any language" as an argument against building a new app in TS. There's truth to what he said, but he's been out of the coding game for a decade and might not realize the paradigm shift full-stack TS is.
Rust is similar. And the hype/trendiness is an argument in its favor! There's a large middle range between garbage tech and golden bullet solutions where self-fulfilling prophecy effects are worth as much as the tech itself. If people believe in Rust it's more likely to succeed.
A nit, but it does now!
IIRC the API coverage is not complete.
Is this because you can still rely on the memory safety of third party Rust packages where you can't with C++?
Others have said most of my thoughts on this one already, but my biggest surprise here was learning that he's only 29 - from the handful of these blog posts (and associated controversies) I've seen I'd totally assumed he was a grumpy old hacker from the 80s!