Some people wont be pleased.
this post was submitted on 11 Mar 2025
160 points (98.8% liked)
Linux
6533 readers
252 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of [email protected] and The GIMP
founded 2 years ago
MODERATORS
Yesterday, we had a presentation at $DAYJOB, where we showed off our software project at a high level to another department. That department does lots of low-level work, including with C.
A team lead from that department, who knows our project, had provided the initial draft for the presentation slides. And they threw a sentence at the end of the slides "By the way: $PROJECT powered by Rust". We were also not the only project there, which explicitly mentioned Rust, even though it wasn't strictly relevant.
And yeah, that's just kind of insane to me. When even management understands that their techies get excited about working with Rust, that's not anymore just a few select voices that call for it. That's a whole department discontent with C, where an alternative is presented.
Which is why I would be extremely surprised, if not something similar happened with the Linux kernel.
Obviously, those who've coded C for twenty years might not understand the issue, but there's so many people for which low-level development becomes accessible for the first time with Rust. The stream of people wanting to contribute Rust code will just not cut off any time soon.
those who’ve coded C for twenty years might not understand the issue
or the opposite because they have that experience
Yeah that's definitely true, but also the people who have been doing it for 20 years have a huge amount of knowledge and experience invested in dealing with memory unsafety. Lots of people don't want that investment to be "wasted", so they try to maintain the status quo, even if it is worse for them.
I could actually see myself contributing to Rust kernel code. C code has always been impossible for me to understand, but the Rust part seems to have a more understandable structure
Rust code (and the ecosystem) seems to put a higher priority on describing code contracts through the type system and documentation. I personally feel you don't need as much context to write functional code compared to C where every corner of the codebase might be hiding something that could impact the part your working on.
This exactly. I always wanted to contribute to the kernel but after being a c++ dev for so many years I absolutely don't want to do C, and rust would allow me to have fun doing kernel hacking
I think this is the most important aspect of Linux accepting more rust contributions. More and more existing maintainers are aging out, and people just don't learn or want to build large applications in C anymore. From what I understand companies doing proprietary kernel development have largely made the rust transition for new code at this point, so fewer and fewer systems level programmers will be used to C (and C++ over time) for these tasks. Existing maintainers pressure against rust development could become a threat to the long term viability of the kernel.
[memory safety] is a more or less solved research problem
I don't know if I would go that far. There are some interesting alternative approaches to Rust's borrow checker that might turn out to be better. There's definitely more research that can be done.
But we do have at least one solution that works very well.
The nice thing is if a much better solution exists then a rust compiler that uses it can be implemented using it. Then you don't have to rewrite all the rust code.
No, the alternative solutions definitely wouldn't work with existing Rust code. You need a new language.
If you don't code with undefined behavior compiler updates can apply to legacy code. I've been through enough compiler upgrades with microcontrollers that it's old hat.
I'm talking about things like Perceus. It's not a compiler update.
Rust++