this post was submitted on 21 Feb 2025
189 points (94.4% liked)

Technology

63082 readers
3604 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
189
Linux royalty backs adoption of Rust for kernel code (www.theregister.com)
submitted 22 hours ago by [email protected] to c/[email protected]
55 comments fedilink hide all child comments
 

Greg Kroah-Hartman... urged fellow contributors to embrace those interested in contributing Rust code to improve the kernel.

"Adding another language really shouldn't be a problem... embrace the people offering to join us

Thoughts on this?

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 20 points 10 hours ago* (last edited 10 hours ago) (2 children)

Despite my drive-by shitposts in the rest of this thread I want to make a serious point here.

There's a large part of software engineering that thinks languages are chosen based on the problem, as a tool for a job.

They aren't. They're chosen based on the team, on how well the team knows and can use the tool. On how many people can be hired with the knowledge of the tool to work immediately.

Sometimes, even if the team knows C well, there can be a problem so different it's worth using another tool. say python for some testing scripts on a C project.

But rust and C are too similar for this to apply. If you want rust to be used for the kernel you have to push for it to be more well known and used, so more Devs come into teams already knowing it well. Anyone agreeing to work on a team using rust is making a career decision that will be stay on their CV forever and you need them to feel good about this, that it will give them more opportunity in future.

It'll take 20+ years because that's how long legacy code is often maintained for and we already have 20+ years of future legacy code for C teams to deal with. We're all making more future legacy C code than future legacy rust code too.

I'm trapped in C++ so I'm doomed but good luck C and Rust coders.

[–] [email protected] 6 points 4 hours ago

"Iam trapped in c++", lol

[–] [email protected] 2 points 4 hours ago (1 children)

Unsafe Rust may be similar to C, though even though there's wibbles like the borrow checker still running, you still get more guarantees about the code than with C. Safe Rust can, on occasion, look more like Haskell than C.

Are they both systems languages? Yes of course otherwise we wouldn't be talking about using them in the kernel. Makes no sense to extend the possible comparison candidates to include Prolog, arbitrarily making look C and Rust more similar by introducing a far-off comparison point.

[–] sugar_in_your_tea 3 points 1 hour ago

Unsafe Rust may be similar to C

It's really not. I'd much rather use C than unsafe Rust...

The best part about Rust is you can isolate your memory safety problems to the unsafe bits, whereas with C, you have to constantly deal with it.

[–] [email protected] 0 points 4 hours ago (1 children)

Rust lacks a language standard. Without that is meaningless programming something with pieces that may change in the future (like what happened with Python) is not a good idea in my opinion.

[–] [email protected] 11 points 3 hours ago* (last edited 3 hours ago)

Technically, the kernel doesn’t compile with pure standard C, they require strict aliasing to be disabled, so that alone doesn’t seem to be strictly required.

Not saying that standards aren’t useful, but they’re not some dividing line separating the true languages from the joke languages, they’re just a useful document that earns a language a few “good language” points, but those points can be earned other ways too.

For example, rust has pretty good versioning, so even if the devs did totally wreck the language in the next version, it’d maintain compatibility with older code just fine, which sort of invalidates your point, unless you’re worried that the devs turn malicious, but the language is open source, so I imagine that would get it forked pretty quickly.

[–] [email protected] 4 points 11 hours ago (3 children)

In my mind, introducing Rust would only make sense if:

  1. There was a serious lack of current kernel developers (which I don't think there is)
  2. New hardware and tech was evolving at a rate that the Linux Kernel could not keep up (again, I don't think this is am issue)
  3. The end goal is to migrate the entire Kernel to Rust.

Regarding point 3, having both C and Rust really only makes sense as a transition phase (measured in years) - as it would require kernel developers to be savvy in both C and Rust, or would force developers to stay within whatever domains were implemented in C or Rust.

[–] [email protected] 9 points 5 hours ago
  1. There was a serious lack of current kernel developers (which I don't think there is)

Maybe not at the moment, but my understanding is that the pool of qualified C programmers is shrinking rapidly, because the old guard is all ageing out and there simply are not enough intermediate developers coding in C at the level that Kernel development requires.

Having a larger (and growing) pool of upcoming developers interested in systems programming and software excellence is one of the explicit stated reasons that Linus et al. considered Rust in the first place.

[–] [email protected] 14 points 9 hours ago (2 children)

it would require kernel developers to be savvy in both C and Rust

From my experience knowing how both C and rust works makes you a better developer in both languages.

[–] [email protected] 4 points 5 hours ago

Learning Rust made me a better C# programmer.

[–] [email protected] 1 points 7 hours ago (1 children)

Oh absolutely, but you could argue the same for learning lisp or mastering any functional programming language (list comprehensions, etc). It will improve your design patterns when you go back to an object oriented language with some elements of functional programming.

[–] [email protected] 5 points 4 hours ago (1 children)

Nah it's a different axis. Rust doesn't have a GC, you do need to think about memory, it's just that the compiler generally enforces things for you. You learn to think like borrowck thinks because you don't want to get yelled at. Going back to C then you suddenly mistrust a lot of code a lot more, and rightly so.

[–] sugar_in_your_tea 3 points 1 hour ago

Exactly. The kinds of things Rust yells at you for, you should consider changing in C as well.

[–] [email protected] 9 points 10 hours ago (1 children)

What's in your mind does not coincide with the professional experience of Greg KH. You shoyld read what he had to say on the subject.

[–] [email protected] 1 points 7 hours ago (1 children)

What?!? Actually, read the article? What is this, Reddit? /s

Seriously, though - let me spin the question around: what, in your mind, overlaps with what Greg said?

(plus, OP was just interested in people opinions - not whether they align/contradict with Greg, Linus, etc)

[–] [email protected] 5 points 7 hours ago (2 children)
[–] sugar_in_your_tea 2 points 1 hour ago

For the lazy, I liked these parts:

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?

...

Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work!

The whole thing is great.

[–] [email protected] 2 points 7 hours ago

To add something to this: linux has avoided internal SPIs for a long time. It's often lauded as one of the reasons it hasn't ossified.

However, some subsystems have a huge amount of complexity and hidden constraint in how you correctly use them. Some of that may be inherent, but more of it will be accidental.

Wrapping type-erased shims around this that attempt to capture (some of) those semantics shines a light onto the problem. The effort raises good technical questions around whether the C layer can be improved. Where maintainers have approached that with an open mind, the results are positive for both C and Rust consumers. Difficult interfaces are a source of bugs; it's always worth asking whether that difficulty is inherent or accidental.

[–] gravitas_deficiency 68 points 22 hours ago (3 children)

I’ve gotten into the most hilariously circular debates with rust opponents on this point. Their arguments tend to come down to “just don’t write bad code”.

The team is only as strong as the weakest link. The release is only as good as the least talented dev. Tools that raise the entire foundation are objectively good. Even better are tools that outright prohibit you from even writing entire categories of bugs. Rust is that tool.

And yeah I know it’s not perfect, and it shouldn’t be treated as a panacea. But its advantages should be lauded, not derided because some contributors like to maintain the walled garden of knowledge as if it were a secret spellbook.

[–] [email protected] 32 points 21 hours ago* (last edited 21 hours ago) (2 children)
  • Humans write code
  • Humans make mistakes

∴ Humans write bad code

[–] [email protected] 19 points 20 hours ago

But some beautiful day in the future, bad code will write badder code.

[–] [email protected] 1 points 20 hours ago

And that's why I don't work in software development!

[–] sugar_in_your_tea 24 points 21 hours ago* (last edited 21 hours ago) (3 children)

I don't know about you, but I prefer provably correct code over "just trust me bro."

There's an analogy I like here. A manager at a trucking company was hiring a new driver, and he asked each of them how close they could get to the edge on a mountain pass. The first said, "I can get within a wheel's width." The second said, "I can drive on the edge, with part of the tire hanging off." And the third said, "I stay away from the edge." The third applicant got the job, because why take the risk?

That's how I feel about C/C++. Why use them if Rust can do the job? You get a lot more safety features without sacrificing performance, what's not to like?

[–] [email protected] 3 points 8 hours ago (1 children)

Because people already know C/C++.

[–] sugar_in_your_tea 2 points 5 hours ago (1 children)

Okay? I know a half dozen languages well, and am pretty productive with a half dozen more. If you're an experienced software engineer, picking up a new language should be easy. If a language is useful for a given task, I use it. If another language offers benefits I want, I learn it.

It's like any other profession, why limit yourself to one tool? If a new tool comes out and does the job better, use it.

I love C and it's my first choice for low level work like microcontrollers. However, it's not great for larger projects, especially ones with significant security concerns, since subtle vulnerabilities in different areas could be combined to create an attack. Rust provides a lot of protection against common attacks without a performance cost, so it's a good choice.

[–] [email protected] 1 points 5 hours ago (1 children)

I think they know C a little better than just to be „productive” with it. And also a lot of those people are not so young anymore to learn a new language well enough to feel comfortable with writing a kernel in.

[–] sugar_in_your_tea 2 points 4 hours ago

As do I. I could jump into a modern C codebase and feel comfortable. I've worked on microcontrollers, built servers (UDP, TCP, and HTTP), and worked with cross thread communication. If I know what I want to build, I can achieve it with C. Maybe not as quickly as someone who works with it every day (it has been a while), but within a month I'd be back in shape.

I feel the same about Python, Go, JavaScript (both on server and FE, either React or straight DOM manipulation), and Rust (I use it for personal projects extensively). When I write C++, it usually turns out like C with vectors and smart pointers, so I'll add that in as well. Except for Rust, I've used all of these in a professional capacity (and I did technically do a couple POCs in Rust). I could list a bunch of other languages I'm less confident in, but could also use professionally if needed without needing to study first.

I'm not suggesting they go out and do the same, I'm merely suggesting that when an option comes along that solves some serious problems they run into every day, maybe they should try it. Most of the languages I mentioned are useless for kernel development, so it makes no sense for them to bother with them. However, Rust is really interesting because it comes with some very compelling guarantees, and you don't get many guarantees when it comes to low level development.

If I told a kernel dev that I had a tool that can identify most if not all memory safety/soundness issues in their C code, they wouldn't hesitate to try it out. But if I ask them to try out Rust (same guarantees), they'll refuse. Why? Hubris and stubbornness.

[–] [email protected] 2 points 9 hours ago

Did somebody say "provably correct"?

Haskell has entered the chat

[–] gravitas_deficiency 10 points 18 hours ago (1 children)

That’s kind the entirety of my point: if Rust is a tool that can make expressing algorithms safer and less prone to error - and it can, in a logically provable sense - then what the fuck ground do you have to push back on?

[–] enumerator4829 1 points 5 hours ago (1 children)

I’m still kind of on the fence about Rust in the kernel. Linux isn’t some random hobby project, there are serious people working for serious companies in the project. Rust has a clear value proposition w.r.t. it’s qualities as a language, but I don’t think it’s as clear on a system level.

Say I’m working for a large company as a dev, maintaining a subsystem (let’s say a driver). Letting other people (filthy casual hobbyists) mess around with their filthy type safety will eventually spill into my subsystem and cause extra work. I don’t want the extra work, I just want to have my driver working and then go home. And even if I’m okay with the extra work, my boss won’t be. Even the risk of extra costs down the line will be enough for some to shut it down completely.

There are boring people working for huge corporations with huge stakes in the Linux kernel. I don’t think they see that much value in Rust at the moment, and I think the Rust crowd might need to hire some MBAs if they want to expand their presence in the kernel.

[–] gravitas_deficiency 1 points 4 hours ago (1 children)

Oh, so that’s actually a thing I specifically do not care about.

I tolerate MBA types at my job because they’re part of an equation that yields a paycheck to me. I don’t believe those MBA types should be in the discussion at this level at all.

In fact, that sort of insistence on implementation details from product and manager types who can’t ever fucking commit to addressing tech debt issues until the system is falling apart is one of the primary frustrations I have in my career.

[–] enumerator4829 0 points 4 hours ago

I don’t believe those MBA types should be in the discussion at this level at all.

That’s the thing. They are in the discussion. It doesn’t matter what we think about it. If touching Rust risks yielding lower profits this quarter, it’s an automatic ”fuck off you filthy hobbyists”. Even having the discussion costs money.

Rust in the kernel isn’t about technology, it’s about economics and risk management. I’d like to see the discussion move on from ”C bad unsafe rust gud typesaf” to a level where the suggested benefits of Rust are made clear to the people holding the bags of money, preferably presenting some actual monetary benefits. (Oh, and to make things worse, there are thousands of different stakeholders, with different interests, many of which are in conflict. Good luck!)

So yeah, I get that you don’t care about it. But you probably should.

[–] [email protected] 11 points 21 hours ago

Their arguments tend to come down to “just don’t write bad code”.

Oooooh, that's a good stratagy! Write that down! Write that down!

load more comments
view more: next ›