Well, concerning memory safety, that might be a more important feature than you think. Allow me to quote a comment I just got an email notification for on a GNOME thread about NVIDIA:
> I wish I could be more optimistic about mutter!3304 coming soon, though... it's been 5 months already, and it doesn't seem anywhere closer to being merged into main To make matters worse, patched mutter 45.5 seems to be causing use-after-free on NVIDIA's kernel driver.
That argument is questionable. C is trivial. The PC architecture is not, and the Linux architecture absolutely not. What makes kernel programming hard is that there is a lot of knowledge that must be internalized, exactly how the DMA works for certain hardware, or why this specific bit need to be set in that lock. There's often no simple way of debugging or single stepping these things without simulating hardware.
The kernel could have been written in assembly with macros, it wouldn't make its development any harder. The best Rust can do is not make kernel more difficult than it already is.
Linus himself made that point a few months ago (https://youtu.be/YyRVOGxRKLg). If you take a look at how devoid large, important, old OSS projects are of young talent in their 20s, 30s and sometimes even 40s it's looking incredibly bleak.
Rust is technically an improvement over memory unsafe language but it also has created enthusiam among largely young and proficient coders. The ecosystem has a lot of dynamism. Drawing those people in is one of the, if not the single most important thing for the health of projects going forward with how many leaders are close to retirement.
Not sure I agree with that. C is a very easy language to learn. The problem with it is that you have to be careful with memory management. That does take effort to learn, and I still make mistakes after writing C for over 20 years.
I love Rust, but it is a very complex language, with a complex, full-featured stdlib, and rich, sometimes-inscrutable type system. It is more difficult to learn than C, but also more difficult (and sometimes impossible) to make many of the mistakes that you can make in C.
Rust isn't that hard to learn, and many of its user come from managed languages who never dared to learn C, because “it's too hard”.
C looks easy on the surface, but the syntax is pretty dated and full of footguns (yes even just the syntax, not even talking about UBs), and learning the language is a pretty intimidating experience because every time you think you know something, you actually don't and get bitten later.
Rust on the other hand is a good language for CS students: you have a lot of things to assimilate upfront, but when you've reached the level required to fulfill the class, you're actually ready to use it in production, and the resulting code produced by a sophomore will be more stable than C code written by wizards.
I know of two old syntactic footguns (assignment vs equality comparison; precedence of bitwise operators) and a single new one no one cares about (sizeof(int)+1 vs sizeof(int){+1}). The rest of the common bugbears look to be caused solely by bad pedagogy (the declaration syntax is not TYPE NAME; the switch statement is a computed goto not a multiarm conditional; there is no separate struct declaration). What am I missing?
Yep. I like to compare C to Brainfuck. Brainfuck is an even smaller, simpler language than C. You can learn Brainfuck in 10 minutes or less. If a language being easy to learn implies that it's easy to use productively, then Brainfuck ought to be one of the most productive languages on the planet! Of course in practice it's so small & so simple & provides so little to the programmer that it's nearly impossibly difficult to use for non-trivial programs.
The ease of writing software in a given programming language is not a linear function of the complexity of the programming language.
Very simple languages are very difficult to use. Very complex languages are very difficult to use. Languages of intermediate complexity tend to be much easier to use than those at the extremes. C is more towards the "simple" extreme than the ideal, Rust is (IMO) a bit more towards the "complex" extreme than the ideal, but is closer to the ideal than C.
I do somewhat doubt that. `no_std` Rust is still quite different from normal, userspace Rust. You don't get all the fancy libraries or whatever (of course Linus would probably just veto them anyway) and the Linux kernel development model is probably quite different (IIRC no cargo and whatnot).
So… what should we reckon? Would there a difference in getting new developers into `no_std` Rust in the kernel, and how different would that be versus having people learn freestanding C, with all the kernel add-ons and nicknacks?
Systems programming is always a full step sideways from traditional applications and I do see where you are coming from.
I would still reckon that having familiarity with the standard rust (even with std) will still have more programmers willing to make the leap than learn C for this one project.
I know of less than a handful of C projects starting in 2024, I know there is a bunch in rust , even with no_std.
Yeah it’s a weird take. The hard part about learning rust is borrow semantics and understanding the kinds of architectures the compiler will and won’t allow.
Well maybe it's just me, but the borrow semantics were never all that bad. Of course there were things that needed to be relearnt, but it's not all that bad all things considered.
Coming from C, the borrow semantics are basically what I try to get anyway, violating them only with suspicion and great care. Rust just makes it easy to check that I didn't screw up what I was already trying to do.
20 years is not a very long time and people are still learning c. My 17 year old intern learned c in college and prefers it over ‘modern crap’ (his words, but he wasn’t talking about rust; JavaScript). We do embedded (low powered mcu’s with a few kb of mem) and I too prefer c over rust for it; it’s a lot easier to attract c than rust people in my experience for this work. Most never touched rust and wouldn’t see a reason for it. Many of them are young.
> My 17 year old intern learned c in college and prefers it over ‘modern crap’
I had a lot of opinions like this too when I was 17, but age and experience has disabused me of many of them.
The embedded story on Rust still has many rough edges, but it's improving every day, and I could easily see it replace C in many places, given enough time (I wouldn't be too surprised if we eventually see companies distributing a BSP that's written in Rust).
Frankly, at this point in time, I think it's foolish to start a new project in C unless you have a really good reason to do so. Many embedded systems certainly qualify as a really good reason, but I very much hope that reason diminishes over time.
> I had a lot of opinions like this too when I was 17, but age and experience has disabused me of many of them.
Sure, I didn't say I agree with them, I barely remember when I was 17, it was that long ago.
I'm saying that young people that I meet are more interested in c so the 'in 20 years no-one knows c' is not exactly true.
We try Rust now and then; it's not worth it yet in my opinion for what we do. The tooling and libs we have for c are vast and like said, c people are really easy to get, Rust not so much.
I hope this changes, but for now it's just too much of a struggle to warrant it. And I was only responding to the fear of not having capable c devs in 20 years. There will be plenty.
That's a very optimistic view on the future of Rust, and a very pessimistic view on the future of C. Chances are that C will be longer around than Rust just because of the Lindy Effect ;)
Kernel C isn't userspace C. The bar for kernel C is much higher and less forgiving than userspace c.
I can't talk about 'telco grade c', because I have never experienced it. I have however seen telco submitted code to upstream kernel and its not above the average quality.
Honestly? Given I've seen crashes and printk messages from AMDGPU with words like "General Protection Fault," I'd say memory safety is probably the most important thing missing in these GPU drivers.