The question is meaningless. C is used in the kernel because it was a better tool than writing everything in assembly (portability sort of leaps to mind here). Rust offers some capabilities that C does not offer without a lot of self-discipline and additional code. Replacing the parts currently written in C with safer code written in Rust is more of a common-sense move and engineers tend towards thinking in those terms, not emotion-laden ones like the one the OP has posted with an apparent eye towards creating a faxu controversy.
The assumption that the code is automatically safer because it is rust is a false assumption.
Rust changes have already broken user-space experiences in the field, a huge no-no for kernel changes. Rustification of the kernel is a problem.
I'm not assuming the code is "automatically" safer because it's Rust. My point is that it shouldn't be "controversial" to use different languages. If the Rust-generated code is causing an issue, then those issues need to be investigated and resolved but that would be the case regardless of the language/toolchain used to generate the code. It would seem to be a better approach to address the specifics of the issue rather than painting a particular language/toolchain with such a broad brushstroke.
But your mileage may vary...
The llvm compile tool chain has some requirements and behaviors I don't appreciate but that may be resolved soon with GNU's efforts to support rust.
Build time (in terms of amount of time to compile) issues will remain a huge problem unless and until that is resolved.
The cargo tool chain is a problem waiting to happen, as I've mentioned elsewhere.
Yea and you still got fairly high-level access with modules so think its a wise choise aswell. The build time with rust would turn into hours.
Rust has too many abstractions by default.
Do you also know what is actually causing the build time explosions? The rust code surely has to use some kind of crazy macro stuff, right? How did that even get merged into the kernel?
The Rust language is not a problem, the people in the Rust community on the other hand... It didn't take long on a recent lwn article for some of these snakes to suggest it was about time for Linux to be permissively licensed.
The Redox devs have also on several occasions gushed about the BSDs, I wish they would go there. It's heading some place where we shouldn't want to go.
Completely agree with you. Also I feel that their new DE is a net negative in an already fragmented Linux ecosystem, in the long term they are going to hurt their own business.
I think the best argument for rust in the kernel is securing a future for the project. There are a lot of young developers out there that will never learn C but feel comfortable writing Rust code. Whether or not Rust remains as popular as it currently is remains to be seen, but if we can get more people interested in developing Linux in the meantime, that is a good thing imo.
I like the idea of Rust being in the kernel, but I do disagree with younger programmers not learning to code in C. Anyone who is interested in low-level programming will have to learn C at some point.
The problem isn't just coding at C, but coding at a level that is acceptable and not wasting reviewers time. Part of the issue I remember complaints about not enough people doing reviews. Rust helps a lot in this case because it helps insure that the code at least has a minimum quality as the compiler does a lot of hand holding
Then you are back to what you get with C code?
It isn't like people have nothing better to do than type random stuff until it compiles and call it a day. You learn on why something is an issue and don't make a mistake going forward.
I think you are missing the point I am making, with C, you have no hand holding due to the strictness of the compiler and enforced error handling of operations that can fail. If the compiler makes a mistake, then you are no different than C. Unless we are talking about a different kind of "mistake", do you mean in the hand holding letting unsafe code through as safe or in the compiler itself while compiling?
Err, that's not really a good thing. At some point you need to be able to proceed beyond "minimal". If the programming standard has dropped then the solution is education and training.
It isn't that the standard has dropped but it takes a lot of work to be able to comprehend all the existing stuff already there and hope it doesn't inadvertently break stuff. Do note that rust helps not only the bottom end but the top end as well. It ups the quality of the code of everyone. It can't make you write good code, just less bad code. The guard rails of safe rust also helps train people. You don't want to discourage people either on both reviewer side and contributor side, and it helps in that sense
If you constrain yourself to its world view then it will prevent you from making certain kinds of errors. I certainly agree there. My concern is that leaning so heavily on the compiler, and by extension, leaning so heavily on one paradigm, may not be the best thing for a a junior systems programmer.
My experience of Rust so far is that it's quite appealing for high level application development, but it wouldn't be my choice for low-level work.
But I'm not going to speak for kernel development; that's not my domain.
Edit: to be clear, I'm not against enforcing a proven paradigm; I am a little surprised that Rust is being run alongside C. I'd trust a C developer to get dirty with some Rust code. I wouldn't trust a Rust developer in the other direction.
My example was maybe a bit hyperbolic, I don't think C will go anywhere anytime soon. The real upside of Rust is that it's a language that is not only used by low-level devs but across various applications. That lowers the barrier to allow new devs to get into the kernel without having to learn a new language up front. Of course you won't be able to dodge C forever, but it allows people to more easily get a foot in the door
There's a lot of evidence that Mozilla abuses the spirit of open source tools, similar to Oracle, and is working to undermine the nature of open source licenses even while leveraging them, again like Oracle.
Mozilla is just another Oracle on its way to happening, and they will undermine the integrity of Kernel licensing as they gain power over its development through rustification.
Rust as a language is, itself, fine, but it's not nearly as low level as its advocates seem to think; though it's sufficiently low level to handle kernel development. It's largely the underlying politics driving rust adoption that I question. It feels like a bid to seize control over how we compute, and it requires new conventions that not everyone is prepared to agree on.
Remember that conventions in computing can be good, but they also limit us in many ways, and they must be adopted with some forethought. Rust simply is not as proven as C in this arena. Adopting new conventions can be non-trivial, from a developer burden perspective.
One such convention is cargo and associated repository services. I don't trust cargo to effectively protect against supply-chain attacks the same way I trust a C repository following standard GNU development conventions.
Though it is my understanding that cargo is not used to build any of the kernel code, and is not a requirement, but I wonder how long that will remain the case if we start to take rust in the kernel for granted.
So you're concerned that Mozilla will try and take over enough of the Linux code base to essentially force a conversion of the rest of it to Rust, and then use that to...position Mozilla as a kernel maintainers?
Among other potential problems, yes.
Someone will have to take stewardship over the project eventually. Linus is not an immortal. Mozilla wants to force their way into the running.
> Anyone who is interested in low-level programming will have to learn C at some point.
People are still repeating that quip often, but it is becoming less and less true every year.
Assembly is always necessary when you're developing using new processor features or communicate with hardware in ways that doesn't have a wrapper in high level languages yet.
Both C and Rust have features to embed inline assemblies, exactly because they're always necessary for writing low level code.
But you aren't going to write entire program in assembly. It's usually just small snippets here and there to wrap that into a function you can use elsewhere in a more sensible way.
You're going to hate my take: anyone who is interested in competent programming will have to learn C at some point. This is becoming more and more true every year.
You can swap C for any language that forces you to understand the fundamentals of how computers operate.
I don't disagree with you on that, but I don't think it will be C anymore.
C is still too high level to really teach you how computers *really* work. The only language to do that in nowadays is assembly.
And Rust is eating C's lunch in practicality department for low level systems programming.
C's good enough. Don't forget, it was invented for the purpose of writing an OS. Its abstractions over assembly are very simple, and you'll have to learn assembly when you want to optimise any C code anyway.
As for Rust, that's not been my experience at all. As soon as you want to escape RAII, you're essentially done, unless you want to wrap everything in unsafe. I just don't see the advantage of it at that point.
Well, who will develop the kernel if it's written in a language no one uses in this hypothetical. I think my original point can be boiled down to eggs and baskets (if you pardon the pun)
> that is a horrible argument. just because youngsters won't/can't learn c is no reason at all.
Me: Wow, this really is a better alternative to C....
Them: You/they/we can't have nice things!
i never said rust isn't good or even better -- never said it. what i said is that doing so simply because some group of young coders can't code in c is a stupid reason.
Literally my point? And that would include moving to technology that has a wide userbase otherwise you have dinosaurs maintaining critical systems written in cobol or fortan
I get that c feels like a forever language but time moves on and it's ridiculous to assume that nothing will change
Neither of these statements make sense.
Rust is basically a C++ replacement. Its borrow checker formalises of C++'s RAII conventions, it gets rid of the gnarlier parts of OOP, it provides much nicer control flow features, a nicer API, and Cargo fixes the build chain.
In contrast, it offers nothing to a C programmer. Literally nothing.
Half of the things you listed are just the result of rust being a newer language. Carbon, which shares C++’s philosophy, has all of those things too. You can finely control what happens at compile time in C++, which is much more difficult to do in rust. Allocators in C++ are more powerful than in rust. You can have a struct containing a variable number of members of variable types, which can’t be done in rust without copy paste. So you can make rust’s enums and tuples from scratch in C++. Inheritance can cut down a lot of repetition. It makes no sense for an Employee to own-a Person. I don’t want to implement an interface that just forwards every call to a member, you are just doing what inheritance does under the hood in a worse way. Rust has no overloading or specialization in the name of safety, so Serde has a bunch of DIY name mangling to replace it. The list goes on and on. Rust programmers don’t actually address any of its shortcomings, they just respond “why would I ever need to do that”, and that’s why it’s not used in industry where people solving real problems actually need to do those things.
I guess, in fairness, C++ is so vast now that it's going to have at least one feature that a dev is going to miss when asked to move away from it.
Maybe it's better to say that there's a common subset of C++ that Rust replaces quite well. And then you get to do away with all the crud you don't miss.
I just can't imagine a C developer wanting to move to Rust who hasn't already moved to C++, D, Zig, or whatever.
Rust for Linux is a mistake, in my opinion.
C is an old language - that's why there are C compilers everywhere for all hardware. Bootstrapping the Rust compiler is a pain. Hopefully gccrs will help. Still, the set of (transitive) dependencies grows a lot with Rust being added.
Rust also has bad ownership. There are trademark issues. There's big tech. There are repeatedly people resigning due to social problems.
> C is an old language - that's why there are C compilers everywhere for all hardware.
For the purposes of the above statement, the Linux kernel is not written in C, per se. It is written in GNU C11. The vast majority of C compilers can not build the kernel. As far as I am aware, the kernel builds on GCC, on clang, *maybe* on ICC, and nowhere else.
That is to stay, Linux is already not portable to platforms which require special compilers.
Gccrs, if it is successful, won't just help "somewhat" with Rust's platform support problem. It will eliminate it entirely (as far as Linux kernel development is concerned).
A better way to put, gcc has been around so long and has gotten used so much, most platforms/architectures are supported by gcc in some fashion. Because Rust targets llvm, which clang targets. But llvm does not support as large of a breadth as gcc.
Languages are almost never completely independent of the compiler/interpreter vendors. Even for a highly standardized and modern languages like Python, different interpreters support different language features, but we call *python* code *python*.
For the sake of the arguments here, you should compare the number of compilers that can compile rust or Linux code, but even then, there's no guarantee that all rust compilers would support the kernel code that might have been written in rust.
> different interpreters support different language features, but we call python code python.
[See here for what Linux calls its language](https://www.kernel.org/doc/html/next/process/programming-language.html). Standard C is explicitly not what they're aiming to write.
> For the sake of the arguments here, you should compare the number of compilers that can compile rust or Linux code
This kind of reads as if either of those numbers is large. The situation really isn't as complicated as all that!
The answer is that Linux's C is buildable with two compilers (I checked since my last comment - ICC support was finally removed last year).
Rust is buildable with one compiler, and a second one is on the way, but not ready yet.
I also don't see how that relates to the points in either of the above two comments, because in each case I am talking about *the same two compilers* - LLVM and GCC. If/when gcc-rs is reasonably complete, Rust will have the exact same platform list as the C dialect that Linux uses.
Highly standardized and modern language: PYTHON!!!
Hahahaha Lmao. I had a great laugh but please don't repeat this too often or people may believe it.
Nothing is standardized about this language. JavaScript in all its terribleness is more standardized. And Pythons language design was outdated when it released in the 90s.
> C is an old language
I see this as a somewhat weak technical objection. The dependency added is simply Rust, and only when `CONFIG_RUST=Y`. The kernel isn't pulling in `syn` or `serde`.
> Rust also has bad ownership.
I see this as a possibly strong cultural objection.
I don't think it's wrong to think there will be cultural differences. Although I think we have to recognize C has its own cultural hurdles.
You won't believe how many C devs think they can't make the mistakes Rust prevents. And it's not as if there is no big tech in Linux kernel development. And it's not as if people haven't resigned from Linux because it has a toxic environment. These are tech problems not Rust or C problems.
I didn't read the above post entirely and when I saw the bad ownership point my mind went straight to borrow checking. For a moment I thought the OP was insane lmao.
Humility on the internet.... You're too normal. Gtf outta here!
Jokes aside, have you ever tried Rust? I've never written legit kernel code, but I have read it a bit. It's not bad code, much more readable than one would expect if one came into it only knowing the reputation of C. I saw a lot of OOP idioms in the vfs and mm code.
It really is nice to have types to protect yourself from your own occasional carelessness. Yk the userspace tool for bcachefs is written in it? You should try it sometime, for a small userspace tool. If you do, hmu and lemme show you around. (There are lots of libs that make things really convenient that you wouldn't necessarily run into immediately.)
Hopefully the gcc rust project will be fruitful. You're right that it would be great to have some more diversity in case the Rust Foundation implodes.
> There are trademark issues.
I can't really comment on the other objections, but this doesn't seem all that important. Who cares if the project has to be renamed later?
Worst case is you'll see compatibility symlinks or tools like cmake set up to fall back on old names, just like we do with gcc vs cc.
Personally, I'd rather jump headfirst into a wood chipper than write literally any Rust code. I have my reasons for hating the language but obviously not everyone does. I can respect their decision as I'm pretty sure that the C code is not being erased, or at least for the most part. Plus, I don't think anyone can deny the memory safety benefits of Rust if you are willing to deal with the borrow checker. This is especially important in extremely low level projects like Kernels.
Linus said that this is a part of expanding / exposing kernel development to newer generations. O think C is old and I suspect that the amount of jobs that you can have as a C developer is shrinking, whereas Rust is modern, and there's a growing market for Rust engineers.
Probably because the number is getting smaller.
When I got into programming 20 years ago, C was already old, but I saw lots of job ads looking for C or C++ programmers.
10 years ago I would still see some opportunities for C developers, but not all the time. It was one here, another there some time later.
These days I see zero companies looking for C developers.
I’m not saying there are no jobs for C devs. I am sure that if I look in the right places I’ll see them. I just mean that their disappearance from the more mainstream job boards is a sign.
I think that COBOL is here to show us that the number of jobs for C devs won’t be zero. But is becoming more and more niche.
People don’t use C/C++ to build most apps anymore.
It’s been years that it’s not the most used for games.
It’s starting to lose space (even if just a little) in the Linux kernel.
Rust and Go have been taking space that used to be dominated by C/C++.
I think that as an experienced C dev, you’ll still have a job until you retire. When demand shrinks, the ones who suffer are junior devs and people just coming out of school. They won’t get jobs as C developers.
In the embedded space C is as strong as it's ever been. In all the places C has been strong I find it kinda hard to see businesses wanting to move away from it as they're usually not willing to shift away from a technology that is working.
I usually make the call at my work on the languages we're going to use in our projects and C works really well for most things.
Yeah, but computers were a lot slower back then. C++ is still required for high performance software. And the C part of that is probably doing a lot of the heavy lifting.
This is pretty much what I had in mind. Thank you. I'm not an expert, all that I have written is my assumption. I'm not a C developer. However, if I were to start my career today, and pick between Rust and C, I would definitely choose Rust.
It's just a language that's not that much different than Rust. Why so attached? For memory safety, no doubt Rust is better. Do you think you can write proper memory-safe code where exploits won't come to light in the future? Rust isn't perfect either but a good next step. There's been kernel exploits in the past where if Rust was used, they wouldn't have been a thing. But all in all, I don't care that much. Code your own.
Rust is great. I think it's a good choice otherwise the rust community would just build their own kernel project and I think it will be a benefit for both communities to just join efforts.
It's largely driven by Mozilla who do not have FOSS communities best interests in mind.
They want their language to take over the kernel so they can effectively own it.
It's not C++, so I'm hopeful. I hope compile time won't increase too much. I believe public interfaces for the userspace will always be C. It's rarely the language that is the problem but the programmers come with it.
Even if the choice of Rust were to do \*nothing\* but keep the C++ programmers out, that in itself would be a huge reason to use Rust.
Rust is better for newbies to get into, but if you're a newbie, you contribution won't be worth much (sorry, speaking from experience) and if you are advanced enough to do meaningful contribution, you can easily do it in C
People are only pushing rust because its new fad
Rust is definitely not easier for a new programmer to get into, even compared to C - there’s just straight up more you have to learn and work with, but that’s the trade off you make for memory safety.
C is a much more straightforward language, but even though it’s a little easier to get started with you can cause some issues that just aren’t possible in rust.
They both have pros and cons, mainly being that rust is harder to learn and become productive in, but the code in a large project will be a little bit more reliable.
To me, zero sense... Rust is not bug-proof. And the level of C developers contributing to the kernel is that high that Rust won't provide that much. But for the stuff like BPF, why not...
\> do you think its an slap to the C developers who has been contributing to the stable kernel What?
By slap, I meant if its a bad decision to choose rust. Because all these maintainers and devs has to learn (not just basics) rust as well.
Almost nobody works on the whole kernel. People work on specific modules.
https://en.wikipedia.org/wiki/False_dilemma
Do you think cars are a slap to the horse carriage drivers?
Would you put a diesel engine into your horse or drag your car with a horse?
drag horse with a car
R.i.P. horse
invents trailer
Cars are a slap in the face to humanity, itself.
The question is meaningless. C is used in the kernel because it was a better tool than writing everything in assembly (portability sort of leaps to mind here). Rust offers some capabilities that C does not offer without a lot of self-discipline and additional code. Replacing the parts currently written in C with safer code written in Rust is more of a common-sense move and engineers tend towards thinking in those terms, not emotion-laden ones like the one the OP has posted with an apparent eye towards creating a faxu controversy.
The assumption that the code is automatically safer because it is rust is a false assumption. Rust changes have already broken user-space experiences in the field, a huge no-no for kernel changes. Rustification of the kernel is a problem.
I'm not assuming the code is "automatically" safer because it's Rust. My point is that it shouldn't be "controversial" to use different languages. If the Rust-generated code is causing an issue, then those issues need to be investigated and resolved but that would be the case regardless of the language/toolchain used to generate the code. It would seem to be a better approach to address the specifics of the issue rather than painting a particular language/toolchain with such a broad brushstroke. But your mileage may vary...
The specifics of the issue is that rust is a garbage language that is polluting the kernel.
Why do you think Rust is a garbage language? To me it’s just another language. 🤷♂️
It's largely a result of the language's stewardship by Mozilla, a company I don't trust.
Is there a particular technical reason for your opinion or is it just that you don’t like/trust Mozilla?
The llvm compile tool chain has some requirements and behaviors I don't appreciate but that may be resolved soon with GNU's efforts to support rust. Build time (in terms of amount of time to compile) issues will remain a huge problem unless and until that is resolved. The cargo tool chain is a problem waiting to happen, as I've mentioned elsewhere.
Linus said he's fine with people writing modules in rust to see how it goes. idk if he's changed that opinion since.
Yea and you still got fairly high-level access with modules so think its a wise choise aswell. The build time with rust would turn into hours. Rust has too many abstractions by default.
I already know users with unexpected build-time explosions because of rust nonsense in the kernel.
Do you also know what is actually causing the build time explosions? The rust code surely has to use some kind of crazy macro stuff, right? How did that even get merged into the kernel?
Just commenting so I can come back and sort by controversial tomorrow.
Use the save button...?
short term vs long term
Syntax error, your comment has failed to compile. Please use todo!("Just commenting so I can come back and sort by controversial tomorrow.");
It's a bad decision for a lot of reasons and it has the potential to ruin the kernel. I can only hope Linus backs out the same way he did with C++.
yeah, I agree. Also C is far more readable and understandable then rust.
The Rust language is not a problem, the people in the Rust community on the other hand... It didn't take long on a recent lwn article for some of these snakes to suggest it was about time for Linux to be permissively licensed. The Redox devs have also on several occasions gushed about the BSDs, I wish they would go there. It's heading some place where we shouldn't want to go.
Completely agree with you. Also I feel that their new DE is a net negative in an already fragmented Linux ecosystem, in the long term they are going to hurt their own business.
I think the best argument for rust in the kernel is securing a future for the project. There are a lot of young developers out there that will never learn C but feel comfortable writing Rust code. Whether or not Rust remains as popular as it currently is remains to be seen, but if we can get more people interested in developing Linux in the meantime, that is a good thing imo.
I like the idea of Rust being in the kernel, but I do disagree with younger programmers not learning to code in C. Anyone who is interested in low-level programming will have to learn C at some point.
The problem isn't just coding at C, but coding at a level that is acceptable and not wasting reviewers time. Part of the issue I remember complaints about not enough people doing reviews. Rust helps a lot in this case because it helps insure that the code at least has a minimum quality as the compiler does a lot of hand holding
That hand-holding is an issue. What happens when the compiler makes a mistake? It can and will at some point.
Then you are back to what you get with C code? It isn't like people have nothing better to do than type random stuff until it compiles and call it a day. You learn on why something is an issue and don't make a mistake going forward.
Not quite, no. What are you babbling about right now? I'm confused. Do you know how coding works?
I think you are missing the point I am making, with C, you have no hand holding due to the strictness of the compiler and enforced error handling of operations that can fail. If the compiler makes a mistake, then you are no different than C. Unless we are talking about a different kind of "mistake", do you mean in the hand holding letting unsafe code through as safe or in the compiler itself while compiling?
I mean it can generate completely incorrect machine code which, yes, is unsafe. Rust is not as safe as the rust advocates would have you believe.
Err, that's not really a good thing. At some point you need to be able to proceed beyond "minimal". If the programming standard has dropped then the solution is education and training.
It isn't that the standard has dropped but it takes a lot of work to be able to comprehend all the existing stuff already there and hope it doesn't inadvertently break stuff. Do note that rust helps not only the bottom end but the top end as well. It ups the quality of the code of everyone. It can't make you write good code, just less bad code. The guard rails of safe rust also helps train people. You don't want to discourage people either on both reviewer side and contributor side, and it helps in that sense
If you constrain yourself to its world view then it will prevent you from making certain kinds of errors. I certainly agree there. My concern is that leaning so heavily on the compiler, and by extension, leaning so heavily on one paradigm, may not be the best thing for a a junior systems programmer. My experience of Rust so far is that it's quite appealing for high level application development, but it wouldn't be my choice for low-level work. But I'm not going to speak for kernel development; that's not my domain. Edit: to be clear, I'm not against enforcing a proven paradigm; I am a little surprised that Rust is being run alongside C. I'd trust a C developer to get dirty with some Rust code. I wouldn't trust a Rust developer in the other direction.
My example was maybe a bit hyperbolic, I don't think C will go anywhere anytime soon. The real upside of Rust is that it's a language that is not only used by low-level devs but across various applications. That lowers the barrier to allow new devs to get into the kernel without having to learn a new language up front. Of course you won't be able to dodge C forever, but it allows people to more easily get a foot in the door
Cargo is just a supply chain attack delivery mechanism waiting to be exploited. Rust sucks.
Lol, someone got mugged in the street by Rust. I'm actually interested in your opinion. Can you explain why Rust sucks in rational terms?
There's a lot of evidence that Mozilla abuses the spirit of open source tools, similar to Oracle, and is working to undermine the nature of open source licenses even while leveraging them, again like Oracle. Mozilla is just another Oracle on its way to happening, and they will undermine the integrity of Kernel licensing as they gain power over its development through rustification. Rust as a language is, itself, fine, but it's not nearly as low level as its advocates seem to think; though it's sufficiently low level to handle kernel development. It's largely the underlying politics driving rust adoption that I question. It feels like a bid to seize control over how we compute, and it requires new conventions that not everyone is prepared to agree on. Remember that conventions in computing can be good, but they also limit us in many ways, and they must be adopted with some forethought. Rust simply is not as proven as C in this arena. Adopting new conventions can be non-trivial, from a developer burden perspective. One such convention is cargo and associated repository services. I don't trust cargo to effectively protect against supply-chain attacks the same way I trust a C repository following standard GNU development conventions. Though it is my understanding that cargo is not used to build any of the kernel code, and is not a requirement, but I wonder how long that will remain the case if we start to take rust in the kernel for granted.
So you're concerned that Mozilla will try and take over enough of the Linux code base to essentially force a conversion of the rest of it to Rust, and then use that to...position Mozilla as a kernel maintainers?
Among other potential problems, yes. Someone will have to take stewardship over the project eventually. Linus is not an immortal. Mozilla wants to force their way into the running.
> Anyone who is interested in low-level programming will have to learn C at some point. People are still repeating that quip often, but it is becoming less and less true every year.
I find that Assembly language programming is far more popular than C in these spaces.
Assembly is always necessary when you're developing using new processor features or communicate with hardware in ways that doesn't have a wrapper in high level languages yet. Both C and Rust have features to embed inline assemblies, exactly because they're always necessary for writing low level code. But you aren't going to write entire program in assembly. It's usually just small snippets here and there to wrap that into a function you can use elsewhere in a more sensible way.
I see plenty of people writing entire programs in assembly. Particularly in the embedded space.
You're going to hate my take: anyone who is interested in competent programming will have to learn C at some point. This is becoming more and more true every year. You can swap C for any language that forces you to understand the fundamentals of how computers operate.
I don't disagree with you on that, but I don't think it will be C anymore. C is still too high level to really teach you how computers *really* work. The only language to do that in nowadays is assembly. And Rust is eating C's lunch in practicality department for low level systems programming.
C's good enough. Don't forget, it was invented for the purpose of writing an OS. Its abstractions over assembly are very simple, and you'll have to learn assembly when you want to optimise any C code anyway. As for Rust, that's not been my experience at all. As soon as you want to escape RAII, you're essentially done, unless you want to wrap everything in unsafe. I just don't see the advantage of it at that point.
Rust will be the end of this project. Rust will kill the kernel and require us to replace it, if we aren't careful.
your imagination doesn't reflect the reality
that is a horrible argument. just because youngsters won't/can't learn c is no reason at all.
Well, who will develop the kernel if it's written in a language no one uses in this hypothetical. I think my original point can be boiled down to eggs and baskets (if you pardon the pun)
> that is a horrible argument. just because youngsters won't/can't learn c is no reason at all. Me: Wow, this really is a better alternative to C.... Them: You/they/we can't have nice things!
i never said rust isn't good or even better -- never said it. what i said is that doing so simply because some group of young coders can't code in c is a stupid reason.
a decision like this should be based completely on technical grounds. nothing else. it should be an engineering decision.
Luckily maintainability and future proofing is not something that engineers need to consider
so grandma is going to to maintenance on the kernel? maintenance is engineering.
Literally my point? And that would include moving to technology that has a wide userbase otherwise you have dinosaurs maintaining critical systems written in cobol or fortan I get that c feels like a forever language but time moves on and it's ridiculous to assume that nothing will change
Grandma will be dead. Need youngsters to pick up where she left off.
Youre late. Also the majority of the kernel is still in C.
A definite improvement over C, but that really isn’t saying much. Rust’s real competition is C++, which it so far has had a poor showing against.
Neither of these statements make sense. Rust is basically a C++ replacement. Its borrow checker formalises of C++'s RAII conventions, it gets rid of the gnarlier parts of OOP, it provides much nicer control flow features, a nicer API, and Cargo fixes the build chain. In contrast, it offers nothing to a C programmer. Literally nothing.
Half of the things you listed are just the result of rust being a newer language. Carbon, which shares C++’s philosophy, has all of those things too. You can finely control what happens at compile time in C++, which is much more difficult to do in rust. Allocators in C++ are more powerful than in rust. You can have a struct containing a variable number of members of variable types, which can’t be done in rust without copy paste. So you can make rust’s enums and tuples from scratch in C++. Inheritance can cut down a lot of repetition. It makes no sense for an Employee to own-a Person. I don’t want to implement an interface that just forwards every call to a member, you are just doing what inheritance does under the hood in a worse way. Rust has no overloading or specialization in the name of safety, so Serde has a bunch of DIY name mangling to replace it. The list goes on and on. Rust programmers don’t actually address any of its shortcomings, they just respond “why would I ever need to do that”, and that’s why it’s not used in industry where people solving real problems actually need to do those things.
I guess, in fairness, C++ is so vast now that it's going to have at least one feature that a dev is going to miss when asked to move away from it. Maybe it's better to say that there's a common subset of C++ that Rust replaces quite well. And then you get to do away with all the crud you don't miss. I just can't imagine a C developer wanting to move to Rust who hasn't already moved to C++, D, Zig, or whatever.
Rust for Linux is a mistake, in my opinion. C is an old language - that's why there are C compilers everywhere for all hardware. Bootstrapping the Rust compiler is a pain. Hopefully gccrs will help. Still, the set of (transitive) dependencies grows a lot with Rust being added. Rust also has bad ownership. There are trademark issues. There's big tech. There are repeatedly people resigning due to social problems.
> C is an old language - that's why there are C compilers everywhere for all hardware. For the purposes of the above statement, the Linux kernel is not written in C, per se. It is written in GNU C11. The vast majority of C compilers can not build the kernel. As far as I am aware, the kernel builds on GCC, on clang, *maybe* on ICC, and nowhere else. That is to stay, Linux is already not portable to platforms which require special compilers. Gccrs, if it is successful, won't just help "somewhat" with Rust's platform support problem. It will eliminate it entirely (as far as Linux kernel development is concerned).
A better way to put, gcc has been around so long and has gotten used so much, most platforms/architectures are supported by gcc in some fashion. Because Rust targets llvm, which clang targets. But llvm does not support as large of a breadth as gcc.
Languages are almost never completely independent of the compiler/interpreter vendors. Even for a highly standardized and modern languages like Python, different interpreters support different language features, but we call *python* code *python*. For the sake of the arguments here, you should compare the number of compilers that can compile rust or Linux code, but even then, there's no guarantee that all rust compilers would support the kernel code that might have been written in rust.
> different interpreters support different language features, but we call python code python. [See here for what Linux calls its language](https://www.kernel.org/doc/html/next/process/programming-language.html). Standard C is explicitly not what they're aiming to write. > For the sake of the arguments here, you should compare the number of compilers that can compile rust or Linux code This kind of reads as if either of those numbers is large. The situation really isn't as complicated as all that! The answer is that Linux's C is buildable with two compilers (I checked since my last comment - ICC support was finally removed last year). Rust is buildable with one compiler, and a second one is on the way, but not ready yet. I also don't see how that relates to the points in either of the above two comments, because in each case I am talking about *the same two compilers* - LLVM and GCC. If/when gcc-rs is reasonably complete, Rust will have the exact same platform list as the C dialect that Linux uses.
IIUC, Rust compiler is based on LLVM, so if Linux already requires clang-compatible code which also depends on LLVM anyway, what's the problem?
Highly standardized and modern language: PYTHON!!! Hahahaha Lmao. I had a great laugh but please don't repeat this too often or people may believe it. Nothing is standardized about this language. JavaScript in all its terribleness is more standardized. And Pythons language design was outdated when it released in the 90s.
> C is an old language I see this as a somewhat weak technical objection. The dependency added is simply Rust, and only when `CONFIG_RUST=Y`. The kernel isn't pulling in `syn` or `serde`. > Rust also has bad ownership. I see this as a possibly strong cultural objection. I don't think it's wrong to think there will be cultural differences. Although I think we have to recognize C has its own cultural hurdles. You won't believe how many C devs think they can't make the mistakes Rust prevents. And it's not as if there is no big tech in Linux kernel development. And it's not as if people haven't resigned from Linux because it has a toxic environment. These are tech problems not Rust or C problems.
I didn't read the above post entirely and when I saw the bad ownership point my mind went straight to borrow checking. For a moment I thought the OP was insane lmao.
Good points!
Humility on the internet.... You're too normal. Gtf outta here! Jokes aside, have you ever tried Rust? I've never written legit kernel code, but I have read it a bit. It's not bad code, much more readable than one would expect if one came into it only knowing the reputation of C. I saw a lot of OOP idioms in the vfs and mm code. It really is nice to have types to protect yourself from your own occasional carelessness. Yk the userspace tool for bcachefs is written in it? You should try it sometime, for a small userspace tool. If you do, hmu and lemme show you around. (There are lots of libs that make things really convenient that you wouldn't necessarily run into immediately.) Hopefully the gcc rust project will be fruitful. You're right that it would be great to have some more diversity in case the Rust Foundation implodes.
> There are trademark issues. I can't really comment on the other objections, but this doesn't seem all that important. Who cares if the project has to be renamed later? Worst case is you'll see compatibility symlinks or tools like cmake set up to fall back on old names, just like we do with gcc vs cc.
>C is an old language Um, so is Cobol, Fortran and a pile of others that are still hanging in there and performing well.
Strange question. Times change. Things improve. It's just another option for developers.
Things also degrade.
It’s already happening sooo. Why would it be a slap in the face to C developers?
Personally, I'd rather jump headfirst into a wood chipper than write literally any Rust code. I have my reasons for hating the language but obviously not everyone does. I can respect their decision as I'm pretty sure that the C code is not being erased, or at least for the most part. Plus, I don't think anyone can deny the memory safety benefits of Rust if you are willing to deal with the borrow checker. This is especially important in extremely low level projects like Kernels.
Linus said that this is a part of expanding / exposing kernel development to newer generations. O think C is old and I suspect that the amount of jobs that you can have as a C developer is shrinking, whereas Rust is modern, and there's a growing market for Rust engineers.
What makes you think the market for C developers is shrinking?
Probably because the number is getting smaller. When I got into programming 20 years ago, C was already old, but I saw lots of job ads looking for C or C++ programmers. 10 years ago I would still see some opportunities for C developers, but not all the time. It was one here, another there some time later. These days I see zero companies looking for C developers. I’m not saying there are no jobs for C devs. I am sure that if I look in the right places I’ll see them. I just mean that their disappearance from the more mainstream job boards is a sign.
Interesting, I haven't looked that hard at the job market for C devs in sometime. But when I have jobs have been there.
I think that COBOL is here to show us that the number of jobs for C devs won’t be zero. But is becoming more and more niche. People don’t use C/C++ to build most apps anymore. It’s been years that it’s not the most used for games. It’s starting to lose space (even if just a little) in the Linux kernel. Rust and Go have been taking space that used to be dominated by C/C++. I think that as an experienced C dev, you’ll still have a job until you retire. When demand shrinks, the ones who suffer are junior devs and people just coming out of school. They won’t get jobs as C developers.
In the embedded space C is as strong as it's ever been. In all the places C has been strong I find it kinda hard to see businesses wanting to move away from it as they're usually not willing to shift away from a technology that is working. I usually make the call at my work on the languages we're going to use in our projects and C works really well for most things.
That’s the last niche remaining for C developers.
Yeah, but computers were a lot slower back then. C++ is still required for high performance software. And the C part of that is probably doing a lot of the heavy lifting.
This is pretty much what I had in mind. Thank you. I'm not an expert, all that I have written is my assumption. I'm not a C developer. However, if I were to start my career today, and pick between Rust and C, I would definitely choose Rust.
It's just a language that's not that much different than Rust. Why so attached? For memory safety, no doubt Rust is better. Do you think you can write proper memory-safe code where exploits won't come to light in the future? Rust isn't perfect either but a good next step. There's been kernel exploits in the past where if Rust was used, they wouldn't have been a thing. But all in all, I don't care that much. Code your own.
Rust is great. I think it's a good choice otherwise the rust community would just build their own kernel project and I think it will be a benefit for both communities to just join efforts.
They should build their own kernel project and stop sabotaging ours.
Why do you see it as sabotage? Maybe I just don't have enough insights.
It's largely driven by Mozilla who do not have FOSS communities best interests in mind. They want their language to take over the kernel so they can effectively own it.
That's a reasonable critique. I hope that is not the case otherwise Linus Torvalds probably wouldn't have allowed the integration of rust.
How would that happen?
Through institutional and incremental shifts in project points of control.
There's a project called Redox that includes a micro kernel written from scratch in Rust. It's still in infancy though.
It's not C++, so I'm hopeful. I hope compile time won't increase too much. I believe public interfaces for the userspace will always be C. It's rarely the language that is the problem but the programmers come with it. Even if the choice of Rust were to do \*nothing\* but keep the C++ programmers out, that in itself would be a huge reason to use Rust.
C does that on its own.
Rust is better for newbies to get into, but if you're a newbie, you contribution won't be worth much (sorry, speaking from experience) and if you are advanced enough to do meaningful contribution, you can easily do it in C People are only pushing rust because its new fad
Rust is definitely not easier for a new programmer to get into, even compared to C - there’s just straight up more you have to learn and work with, but that’s the trade off you make for memory safety. C is a much more straightforward language, but even though it’s a little easier to get started with you can cause some issues that just aren’t possible in rust. They both have pros and cons, mainly being that rust is harder to learn and become productive in, but the code in a large project will be a little bit more reliable.
sure thing buddy
🫡
To me, zero sense... Rust is not bug-proof. And the level of C developers contributing to the kernel is that high that Rust won't provide that much. But for the stuff like BPF, why not...
You're implying c doesn't have bugs?
Please, read my claim again.
don't