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.
this post was submitted on 21 Feb 2025
221 points (94.7% liked)
Technology
68130 readers
3501 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
Comparing python to rust, rust has far fewer breaking updates than python, and thats a fact. Feature updates can and do break older code in python, whereas in rust this is simply not allowed with few exceptions.
The language is allowed to change in compatible ways with editions. Every few years a new edition is released which allows otherwise breaking changes to be implemented, but the old and new code can still work together. Developers can rev the edition version when they want. I also think cargo might be able to help upgrade to a new edition as well.
Rust isn’t perfect, but python fails to learn the lessons that even perl implemented decades 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.
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.
"Iam trapped in c++", lol
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.
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.
In my mind, introducing Rust would only make sense if:
- There was a serious lack of current kernel developers (which I don't think there is)
- 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)
- 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.
- 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.
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.
Learning Rust made me a better C# programmer.
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.
Again from my experience, knowing lisp (yay guix and emacs) definitely helps me write more elegant code in every language.
I also have to explain almost every single thing I write in code review.
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.
Exactly. The kinds of things Rust yells at you for, you should consider changing in C as well.
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.
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)
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.
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.
view more: next ›