Rust is a relatively new programming language. Similar to C or C++ it compiles directly into executable binary code so it can be used for bare metal or low level operating system programming. It is thus relevant to Linux kernel development as things like drivers can and are being developed in Rust.
Compare this to the likes of Java or C# which get compiled to bytecode or a kind of pseudo machine code that gets run in a virtual machine, which has advantages for application development, or something like Python which is interpreted (or just-in-time compiled) at run-time, useful as an end user scripting language.
Rust is designed from the ground up to tackle some modern problems, a key one being memory safety. It’s a lot more paranoid about memory allocation and access and it’s structured around this. Older languages like C allow the programmer a lot more absolute control over the hardware, which effectively means the C programmer has a lot more footguns in his toolbox. Theoretically, Rust offers fewer opportunities for the developer to shoot himself in the foot.
Rust also comes with some really cool tooling. Compiler errors usually point straight at the problem and say something like “Shouldn’t there be a colon here?” The build system, called Cargo, is really slick in a lot of ways, handling linking, compiling, even library package management in a very automatic fashion. It’s real slick to work with.
As with anything, fans of the language can be a bit much; they stereotypically suggest rewriting everything under the sun in Rust whether it makes sense or not, and this includes the Linux kernel, which has caused some friction in the community; Linux contributors are often very accustomed to C and some don’t want to deal with anything else.
I listen to Steve Gibson’s podcast “Security Now” and he was talking about why, for security reasons, memory safe applications should be the way of the future. So many security vulnerabilities come from improper memory management. And while C may be more powerful, giving up some of that power for standardization is almost always worth it. We could make much more progress if we were spending less time trying to make sure the memory is handling correctly in every situation. So while there is no doubt the crazy fans of it, I think moving to memory safe languages in general should be the way of the future.
Of course, he still writes all his programs in assembly and refuses to learn anything else. But when you’re at his age, I guess you get a pass XD
I’m convinced MS is funding the rust foundation only so that the rust kernel rewrite will fracture the Linux ecosystem and weaken it’s overall standing.
the fact that any rust community I’ve had the displeasure of working with is toxic as fuck only fuels my theory that MS wants it as inhospitable as possible to keep existing kernel devs “in their lane”.
it’s really not a bad language, but the devs… ohhh boy…
I like the description by a Finn who said: Rust is like a car with automatic, while in C (or Zig) you need to change the gears. In Rust you literally follow the compiler, which allows many young developers to program at low level, while C demands more time to avoid bugs. It is up to each person what he/she prefers. I would prefer to control myself the stuff and learn the in and outs of memory management.
I like the description by a Finn who said: Rust is like a car with automatic, while in C (or Zig) you need to change the gears.
I don’t think this metaphor is correct. The automatic gear’s analogy would be the Garbage Collector, which almost every mainstream language has. Rust’s memory management, in comparison, is still manual. Maybe not as manual as C or Zig - but I’d say about as manual as C++. The difference is not that it has some weird gear-changing (memory cleanup) scheme that does not require human intervention - it’s that it yells at you when you don’t do the regular gear changing (memory management) properly.
I found the article, or better opinion. My bed that it wasn’t a Finn, but an America, Alan Ward. The metaphor is taken from him, while he explains in his article much better than me. Please, see his opinion on page 48-49 in the linked PDF of the current Full Circle issue #215 below:
It’s fair to want to learn (and it’s certainly a good skill to have), but the question is what you’d rather see in a large, production environment. Guard rails are usually there for a reason. As for the control: you actually can program memory-unsafe (and in kernel development you often have to!) in Rust. The difference is that in Rust it’s explicitly marked by an unsafe block:
unsafe {
...
}
That way you get the same, fine-grained control over low-level processes, but someone else reading your code can at a glace spot where potential memory bugs may be.
In the end, languages are a tool. Especially for personal projects, everyone should just go with what’s fun to them. I personally think it makes sense, logistically, to slowly transition legacy C-based projects to Rust, because it makes onboarding new developers easier, while keeping the same memory safety that requires years of experience otherwise, basically for free. But there’s really no rush to rewrite anything that’s working well in Rust
Alas, when there is no difference between unsafe wrapper in Rust and C, then why learning Rust, if one wants to go for managing the memory manually? Especially when considering the complex way of coding in Rust?
Another problem: going the easy way and forgetting the tricky parts - if Rust allows for unsafe code, but it is safer to put it into a « safe » mode, so why I need to take the burden and deal with unsafe code? This will evidently lead to the situation that less and less unsafe blocks will be used, which finally leads to a situation where the programmer forgets the in and outs of manual memory management. You can see it as the principal aim of writing memory safe code, but to me it is also a way of « delearning » by learning. I see here the reason why so many young programmers are opting for Rust, because manually managing the memory in larger projects like in C is a question of knowledge and experience which does not come in one day. I also doubt that following just the compiler is a good approach.
I agree totally with your last points though! Coding should mean to have fun and be the same time mentally challenged due to complex algorithms or demand for better code in general.
Actual answer:
Rust is a relatively new programming language. Similar to C or C++ it compiles directly into executable binary code so it can be used for bare metal or low level operating system programming. It is thus relevant to Linux kernel development as things like drivers can and are being developed in Rust.
Compare this to the likes of Java or C# which get compiled to bytecode or a kind of pseudo machine code that gets run in a virtual machine, which has advantages for application development, or something like Python which is interpreted (or just-in-time compiled) at run-time, useful as an end user scripting language.
Rust is designed from the ground up to tackle some modern problems, a key one being memory safety. It’s a lot more paranoid about memory allocation and access and it’s structured around this. Older languages like C allow the programmer a lot more absolute control over the hardware, which effectively means the C programmer has a lot more footguns in his toolbox. Theoretically, Rust offers fewer opportunities for the developer to shoot himself in the foot.
Rust also comes with some really cool tooling. Compiler errors usually point straight at the problem and say something like “Shouldn’t there be a colon here?” The build system, called Cargo, is really slick in a lot of ways, handling linking, compiling, even library package management in a very automatic fashion. It’s real slick to work with.
As with anything, fans of the language can be a bit much; they stereotypically suggest rewriting everything under the sun in Rust whether it makes sense or not, and this includes the Linux kernel, which has caused some friction in the community; Linux contributors are often very accustomed to C and some don’t want to deal with anything else.
I listen to Steve Gibson’s podcast “Security Now” and he was talking about why, for security reasons, memory safe applications should be the way of the future. So many security vulnerabilities come from improper memory management. And while C may be more powerful, giving up some of that power for standardization is almost always worth it. We could make much more progress if we were spending less time trying to make sure the memory is handling correctly in every situation. So while there is no doubt the crazy fans of it, I think moving to memory safe languages in general should be the way of the future.
Of course, he still writes all his programs in assembly and refuses to learn anything else. But when you’re at his age, I guess you get a pass XD
I’m convinced MS is funding the rust foundation only so that the rust kernel rewrite will fracture the Linux ecosystem and weaken it’s overall standing.
the fact that any rust community I’ve had the displeasure of working with is toxic as fuck only fuels my theory that MS wants it as inhospitable as possible to keep existing kernel devs “in their lane”.
it’s really not a bad language, but the devs… ohhh boy…
Windows already has Rust in their kernel
I like the description by a Finn who said: Rust is like a car with automatic, while in C (or Zig) you need to change the gears. In Rust you literally follow the compiler, which allows many young developers to program at low level, while C demands more time to avoid bugs. It is up to each person what he/she prefers. I would prefer to control myself the stuff and learn the in and outs of memory management.
I don’t think this metaphor is correct. The automatic gear’s analogy would be the Garbage Collector, which almost every mainstream language has. Rust’s memory management, in comparison, is still manual. Maybe not as manual as C or Zig - but I’d say about as manual as C++. The difference is not that it has some weird gear-changing (memory cleanup) scheme that does not require human intervention - it’s that it yells at you when you don’t do the regular gear changing (memory management) properly.
I found the article, or better opinion. My bed that it wasn’t a Finn, but an America, Alan Ward. The metaphor is taken from him, while he explains in his article much better than me. Please, see his opinion on page 48-49 in the linked PDF of the current Full Circle issue #215 below:
Full Circle #215
I find his metaphor very apt.
It’s fair to want to learn (and it’s certainly a good skill to have), but the question is what you’d rather see in a large, production environment. Guard rails are usually there for a reason. As for the control: you actually can program memory-unsafe (and in kernel development you often have to!) in Rust. The difference is that in Rust it’s explicitly marked by an unsafe block:
unsafe { ... }That way you get the same, fine-grained control over low-level processes, but someone else reading your code can at a glace spot where potential memory bugs may be.
In the end, languages are a tool. Especially for personal projects, everyone should just go with what’s fun to them. I personally think it makes sense, logistically, to slowly transition legacy C-based projects to Rust, because it makes onboarding new developers easier, while keeping the same memory safety that requires years of experience otherwise, basically for free. But there’s really no rush to rewrite anything that’s working well in Rust
The sound bite I heard was “the unsafe keyword makes memory bugs greppable.”
Alas, when there is no difference between unsafe wrapper in Rust and C, then why learning Rust, if one wants to go for managing the memory manually? Especially when considering the complex way of coding in Rust? Another problem: going the easy way and forgetting the tricky parts - if Rust allows for unsafe code, but it is safer to put it into a « safe » mode, so why I need to take the burden and deal with unsafe code? This will evidently lead to the situation that less and less unsafe blocks will be used, which finally leads to a situation where the programmer forgets the in and outs of manual memory management. You can see it as the principal aim of writing memory safe code, but to me it is also a way of « delearning » by learning. I see here the reason why so many young programmers are opting for Rust, because manually managing the memory in larger projects like in C is a question of knowledge and experience which does not come in one day. I also doubt that following just the compiler is a good approach. I agree totally with your last points though! Coding should mean to have fun and be the same time mentally challenged due to complex algorithms or demand for better code in general.