Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

171–180 of 853 posts

Re: Rust in the kernel is no longer experimental

#171

Earlier quoted context omitted.

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library. https://doc.rust-lang.org/src/alloc/collections/linked_list....

I think that misses the point though. C trusts you to design your own linked list.

It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...

Re: Rust in the kernel is no longer experimental

#172
post #155

Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.

I am not a system programmer but, from my understanding, Torvalds has expressed strong opinions about microkernels over a long period of time. The concept looks cleaner on paper but the complexity simply outweighs all the potential benefits. The debate, from what I have followed, expressed similar themes as monolithic vs microservices in the wider software development arena.

Re: Rust in the kernel is no longer experimental

#173

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

A C compiler is easier to bootstrap than a Rust compiler.

Re: Rust in the kernel is no longer experimental

#174

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc. there u can likely explore well the boundaries where rust does and does not work. people have all kind of opinions. mine is this: if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems r…

I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants.

It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad.

Re: Rust in the kernel is no longer experimental

#177
post #72

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases.

I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.

C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.

People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.

Re: Rust in the kernel is no longer experimental

#178

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

>does C hold any significant advantage over Rust

Yes, it's lots of fun. rust is Boring.

If I want to implement something and have fun doing it, I ll always do it in C.

Re: Rust in the kernel is no longer experimental

#179
post #133
post #6

Earlier quoted context omitted.

That is why most of the world has not been using c/c++ for decades.

People didn't use seatbelts before seatbelts were invented.

And when they were mandated, it made a lot of people very angry!

https://www.cbc.ca/player/play/video/1.3649589

Re: Rust in the kernel is no longer experimental

#180

Oh dear can you imagine the crushing complexity of a future Rust kernel.

Complexity of Rust is just codifying existing complexity.

I've been working on Rust bindings for a C SDK recently, and the Rust wrapper code was far more complex than the C code it wrapped. I ended up ceding and getting reasonable wrappers by limiting how it can be used, instead of moddeling the C API's full capabilities. There are certainly sound, reasonable models of memory ownership that are difficult or impossible to express with Rust's ownership model.

Sure, a different model that was easy to model would have been picked if we were initially using Rust, but we were not, and the existing model in C is what we need to wrap. Also, a more Rust-friendly model would have incured higher memory costs.

Post reply on HN