from qaz@lemmy.world to linux@lemmy.ml on 20 Feb 09:06
https://lemmy.world/post/25824100
But for new code / drivers, writing them in rust where these types of bugs just can’t happen (or happen much much less) is a win for all of us, why wouldn’t we do this? C++ isn’t going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.
Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to “ensure that you got this right” that is a combination of both how our apis have evolved over the years (how many different ways can you use a ‘struct cdev’ in a safe way?) and how C doesn’t allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.
And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I’m willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.)
Rust isn’t a “silver bullet” that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn’t we want that?
threaded - newest
Took way too long, but finally some support from the top leadership for rust?
Linus has also declared Rust as basically inevitable before, since more and more kernel maintainers retire and not many young devs learn C anymore, at least not to a proficiency where you can handle kernel development.
Fixing things that aren’t broken serves only to break them.
I’ll take “why is my codebase full of technical debt” for 500, Alex.
Considering the amount of CVEs the kernel puts out, I’d argue there’s plenty there that’s broken, and could be fixed by implementing them in a language less broken than C.
But I know my language and never make mistakes. Don’t know how many times I hear that. If that was true we wouldn’t be having by these problems.
Sounds like something is broken.
People have commented on the stability side, but there’s also the new implementation side. Seasoned developers have hailed Rust as being better for development - look no further than the GPU drivers for an example
that same logic was used by American auto manufacturers, then their vehicles became obsolete as the competition had been improving their designs to be more efficient.
That’s an example of not fixing something that is broken.
the designs worked just as well as when they were new, the competition just got better though
If even senior C developers can and regularly do write critical memory vulnerabilities that can give attackers remote code execution as root, then I’d say it’s indeed already broken.
Greg is a great level head in the kernel regarding rust, at least among the senior maintainers. I hope he can convince some of the more hostile maintainers to accept the new status quo that includes Rust in the Kernel at all levels.
Phoronix’s comment section is as toxic as it can be, but i found out a comment that puts into words better similar thoughts I have on this:
I’d only add that it’s not only about the kernel - they are home to a project that could be in the medium-long term a serious alternative to Google’s blink/Apple’s webkit, and of course an alternative to the hegemony of Chrome, but they actively chose to just not give them a single cent. Yes I am talking about Servo.
It really isn’t that simple though. Rust’s compiler isn’t stable because the language itself is still being improved. This type of thing will only improve as adoption increases and real-world problems get ironed out. You can’t just throw money and devs at it and expect the problem to be solved.
It’s also not like the developers don’t care about compile time, but the nature of the language (strict compiler checks which catch things before runtime) will inherently lead to something slower that other languages’ compilers. There are probably still improvements they can make, but it’s not as simple as just deciding to rewrite/revamp it and expecting massive speedups.
Then nobody will throw money at any project at all, because everything eventually will be solved by “magick”.
Destinating more resources to that quickens and makes better that process, though, incentivating people to work on it and test it.
That’s one of the reasons why you get delayed or cancelled, over-budget projects that go nowhere. ( another big one is corruption and general financial shenanigans ).
if you throw a lot of money at a problem/project that doesn’t have reasonable management and competent understanding of where that money could work efficiently then you’re asking for trouble.
That is charmingly naive, in my experience.
I’m not saying more money wouldn’t help, I’m saying throwing money at it isn’t generally a stand-alone solution, which is what i think the person you were replying to was trying to say.
It’s not magic, it’s adoption rates. I’m not saying the money or resources are useless, but as it is right now, I think more people would benefit from actually trying to use rust in more large-scale projects (like R4L, windows, android, redox, servo, etc.) and using that experience to inform actual language development. I don’t think it makes sense to do a full revamp of the compiler until projects like those are actually proven. In the meantime it makes more sense to allocate funding/dev resources to those projects (or at least the open source ones)
Every time Rust takes forever to compile something, I picture in my mind it checking every possible edge case and buffer vulrnability I didn’t check and suddenly I’m a lot more okay with how long it takes.
People like to be on commitees to feel important. The issue becomes what their role should actually be. Unfortunately donors end up on commitees and part of the decision making process. They have their own motivations and incompetencies.
I’m not a programmer so i don’t have much skin in the game, but from how it’s described it seems like a good idea to me and rust seems like a solid language to me. I do understand the concern from devs who don’t know rust and don’t want to learn it, but i guess that also depends on how much they would actually have to interact with it.
The main problem is that Rust is immature. It’s still evolving, and the unreliable compiler slowly generates bloated binaries.
It’s a great idea, and it will get there, but shoving something incomplete into the mainline Linux kernel isn’t the way to start.
A Rust-only fork, on the other hand, would do much more to test and prove Rust’s utility in such a space.
To point it out for folks unfamiliar with Rust, I consider this comment borderline misinformation.
I don’t know in what world the Rust compiler is considered unreliable. In my experience, it is one of the most reliable toolchains across all programming languages.
The Rust compiler is slow, because it does so many more checks than the C compiler, which is what these devs want. This is also barely relevant while actually developing, because then incremental compilation kicks in, which makes subsequent builds rather quick.
And Rust binaries are primarily larger than C binaries, because it does not use dynamic linking of dependencies. In the kernel, you cannot use dynamic linking anyways, because you need a running kernel to have a filesystem from which to dynamically load these.
Anyone who replies to this with “any mistakes in C code are the developer’s fault” should be banned from the kernel. I know someone’t going to try it.
“We don’t need TCAS on commercial airliners because any colisions are the pilot/controller’s fault”
So true
Reminder that Linux’s decision to write an entire kernel in C and not a mix of C and assembly was just as controversial back then as Rust vs C is now. The pro-assembly programmers used many similar arguments as the anti-Rust programmers (it’s bloated, it’s too high level for the kernel, it has a complicated compiler, it’s just a pointless abstraction over what’s actually happening at the processor level, it’s not mature enough, if you were competent in assembly you wouldn’t need to use C, if assembly is too difficult for you then you shouldn’t even be developing a kernel, etc). Now Linux is hailed as one of the pioneer software projects that led the switch from assembly to C for kernel level code.
was linux ever in majority assembly? was the C thing added on by a separate team?
Maintenance. The concern is maintenance.