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

Technology

63082 readers
3556 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
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 24 points 22 hours ago* (last edited 22 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] 10 points 15 hours ago

"Iam trapped in c++", lol

[–] [email protected] 2 points 16 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.

[–] [email protected] 3 points 12 hours 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.