linux is amazing. i dunno what rust is, but ive been using linux a long time. i appreciate the modern comfort. but whatever happens happens. itll still be good.
If code doesn’t change quickly enough, it rusts. Linus makes sure that doesn’t happen
Removed by mod
This is just a dick measuring contest.
Rust people are so annoying.
counterpoint: stonewalling c programmers are so annoying.
This whole thing reads not like a codebase versus, but a traditional engineering approach (don’t act like you can patch this once you release it - get it done so it’s stable the first time) versus the more modern “move fast and break things” approach.
that article is horrible to read! every paragraph starts with quotation, but then never closes it😵
That’s how that works normally
Can someone distill the good faith argument against rust? Is there one?
Only one compiler nailed to LLVM. And other reasons already mentioned.
Syntax ugly
Can someone distill the good faith argument against rust? Is there one?
The problem is that even if it’s objectively better, you can’t magically convert everything instantaneously, and it’s a lot more work maintaining rust and C versions of the same code until everything is re-implemented in rust.
If the rust devs are willing to take on that work, what’s the problem?
It will take more effort than writing kernel from scratch. Which they are doing anyway.
(n.b. I am neither a rust, nor C developer so I am writing outside my own direct experience)
One of the arguments brought up on the kernel.org thread was that if there were changes to the C side of the API, how would this avoid breaking all the rust bindings? The reply to this was that like with any big change in the Linux kernel that affects multiple systems with multiple different teams involved, that it would require a coordinated and collaborative approach — i.e. it’s not like the rust side of things would only start working on responding to a breaking change once that change has broken the rust bindings. This response (and many of the responses to it) seemed reasonable to me.
However, in order for that collaboration to work, there are going to have to be C developers speaking to rust developers, because the rust developers who need to repair the bindings will need to understand some of what’s being proposed, and thus they’ll need to understand some level of C, and vice versa. So in practice, it seems nigh on impossible for the long term, ongoing maintenance of this code to be entirely a task for the rust devs (but I think this is taking an abnormally flexible reading of “maintenance” — communicating with other people is just part and parcel of working on such a huge project, imo)
Some people have an ideological opposition to there being two different programming languages in the Linux kernel full stop. This is part of why the main thing that rust has been used for so far are drivers, which are fairly self enclosed. Christoph Hellwig even used the word “cancer” to describe a slow creep towards a codebase of two languages. I get the sense that in his view, this change that’s being proposed could be the beginning of the end if it leads to continued prevalence of rust in Linux.
I haven’t written enough production code to have much of an opinion, but my impression is that people who are concerned are valid (because I do have more than enough experience with messy, fragmented codebases), but that their opposition is too strong. A framework that comes to mind is how risk assessments (like are done for scientific research) outline risks that often cannot be fully eliminated but can be reduced and mitigated via discussing them in the context of a risk assessment. Using rust in Linux at all hasn’t been a decision taken lightly, and further use of it would need ongoing participation from multiple relevant parties, but that’s just the price of progress sometimes.
it’s more niche than C, has less competency available, works very differently to C, and requires a whole new toolchain to be added to the already massive kernel compilation process. for it to be plain sailing adding it to the kernel some of the worlds’ foremost domain experts on operating systems would have to re-learn basically everything.
also since rust is just coming up on 15 years of existence without a 1.0 release, there’s no way to ensure that the code written today will be considered well-formed by the time 1.0 hits.??? Rust 1.0 was released 10 years ago and since then there have been no breaking changes.
so it was! cool!
i will admit i’m not very well versed in rust, the only time i’ve used it was in like 2016, in an embedded context where there were hard restrictions on what could be used. no crates, no macros, no traits, no threading, and a very limited number of functions. procedural style, basically. someone else chose the wrong language and i just had to work within the system.
if the language is stable, i’m assuming the instability issues come from external crates? or are they just made up?
I havent noticed any problems with instability, at least for web server development it is stable enough. But it may be different in other contexts like embedded. And its true that many libraries still have 0.x versions.
for it to be plain sailing adding it to the kernel some of the worlds’ foremost domain experts on operating systems would have to re-learn basically everything.
This is the core problem. It’s a social problem, not a technical one.
The quote he replied to:
If shaming on social media does not work, then tell me what does, because I’m out of ideas.
Yeah, lol
Yeah, Linus conspicuously did not answer that question either.
Could someone explain the backpedalling if rust is more secure ?
it’s a different technology and paradigm that the old guard would have to take considerable time to learn to be as productive as they are in C. it requires a different way of thinking about systems.
basically the rust-in-kernel-gang includes none of the “main” kernel team because they are busy building the kernel. this is an experiment to see if a second programming language can be successfully integrated into the kernel at all. if they try to force their way in, that’s going to cause problems for everyone.
Okey,
Same old story with any project with different generations. Looks like the old guys are in the wrong - wont be here forever and there by have to let in new ideas and ways.
I think this comment encapsulates the problem well: laymen who are not involved in the process in any way (on either side) acting like armchair experts and passing harsh judgement. You’re making some very unfair assumptions based on age, and nothing about the actual technical arguments.
This is why people like Martin feel justified going on social media to publicly complain, because they know they’ll get a bunch of yesmen with no credible arguments to mindlessly harrass the developers they disagree with. It’s childish and unproductive, and while I’ve personally respected Martin as a developer for a long time, I don’t believe he’s mature enough to be involved in the Rust for Linux effort (tbf, he’s not the only Rust dev with this attitude). If the project fails, it will be because of this behavior, not because of the “old guys” being stubborn.
I don’t care about age, if your sharp - your sharp. Old guys where more describing those in charge not wanting to let anyone in who doesn’t do things like they do. Just thought “old guards” sounded so… lame.
Seen this a bounch of times in other projects and it ends up with good ambitious people leaving. Young blood that in the long run is needed to keep a project like this alive.
laymen who are not involved in the process in any way (on either side) acting like armchair experts and passing harsh judgement.
It doesn’t matter what laymen say, so how can they be the problem?
This is why people like Martin feel justified going on social media to publicly complain, because they know they’ll get a bunch of yesmen with no credible arguments to mindlessly harrass the developers they disagree with.
Did Hector call people to action to harass the developers that “they disagree with”? Or did they try to promote awareness on the issue that is clearly causing them frustration? They certainly questioned whether or not there was another way besides shaming people on social media and it shows potential growth from my perspective.
If the project fails, it will be because of this behavior, not because of the “old guys” being stubborn.
Social media is another medium to express yourself and communicate ideas - it is neither good nor bad. If a project that is already developed pretty openly cannot address the criticism by social media/the public of their statements and behaviors, then perhaps they should privatize their communications. Or perhaps just address the criticisms in good faith and explain themselves in the spirit of open source.
my take on the social media thing is that it basically amounts to creating an outside context problem. gathering the opinions of us plebs doesn’t really matter because the kernel isn’t developed by the masses, no matter what ESR thinks. the project is headed by Linus (and his “generals”) and what they say goes. so riling up a bunch of nobodies that aren’t fully aware of all the requirements there are on the kernel will amount to brigading no matter how well-meaning the mob is.
the LKML exists and is public specifically because they don’t want to deal with fielding questions from people on social media. they want to field questions from people who care enough to read it.
actually, they did try using social media for a while. unfortunately they chose google plus.
the linux kernel is over 30 million lines of code. it may not be there forever, but good luck phasing it out in a lifetime.
Old people fear change
People who has been maintaining the kernel and weathered multiple fads are wary to see if new guards will “stick”, or just stay along for a year or five, disappear and leave the old guard with shit.
Thats also true…
Initially it sounded like that…
Honestly I kinda wish the Rust devs would rather go and support a project like Redox OS and then maybe we can have less drama about all this.
Rust is the future for this sort of systems programming work, and by failing to see that and accommodate its use both Linus and Hellwig are sabotaging the long term viability of the kernel imo. New devs are keen to jump on rust because of how much it does better than C/++ and how much easier it is to make safe and secure systems with it, but shit like this just demotivates that crowd and thins the pool of people who are willing to contribute going forward. We need memory safety by default, the task of kernel stability is only going to get more complex and unsustainable without it. Stop holding onto tradition and purity for the sake of it
Rust is not the only systems language with “memory safety”. Some even have better type systems (linear types, refinement types, GADTs) & tools for proving code correct. What grinds my gears is this “C is has problems, therefore you must use Rust” flawed mentality.
I agree but in terms of the features, momentum, and community around rust I think it’s the most promising option for memory safe language. But you’re right that it’s not the only option, I should say that they should be more welcoming to mixed language development with memory safe languages in general
Rust has affine types and gets close to linear when you include
#[must_use](you can stilllet _ = foobut at least it won’t be an accident, also, drop code isn’t guaranteed to run and there’s good reasons for that), refinement types there’s a library for that. GADTs… I mean sure trait magic can get annoying and coming from Haskell you’d want to do more in the type system but in the end the idiomatic rust way to do many of those things is with macros. Which, unlike Haskell, Rust actually is really good at. Really good. Tack refinement types onto the language kind of good.Proving tools, honestly, there’s only one piece of actually proven software (SeL4) and the only language it’s really written in is Coq. Which Rust will never, ever, compete with on its home turf.
- Can’t do it
- Requires library, not built-in
- Can’t do it
- Can’t do it
Not sure why Haskell is being invoked—several languages have GADTs & macros.
Two things can be true at once:
- More Rust in the Linux kernel is good
- Brigading on social media is bad
Open source work is collborative. No matter how good an engineer someone is, if they can’t figure out how work with others, then it’s better to kick them out. A potentially insecure kernel is better than a non-existent one.
I agree. I think Hector Martin should not have endorsed that sort of behavior to whatever extent he did. But I also think long term that the sorts of behavior that’s keeping these rust patches out of the code base will kill the future of the project. The reasons given aren’t even applicable since the patches are in their own branch of the tree. But I agree brigading is not the way to address these sorts of organizational issues
Agree, I think if Linux doesn’t find a good way to include and maintain rust, redox will replace Linux in the long term
MIT X11-style license
BSD on rust. Will meet same fate long term unless they move to GPL or more copyleft.
FTA: "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
"Because if we have issues in the kernel development model, then social media sure as hell isn’t the solution. The same way it sure as hell wasn’t the solution to politics.
“Technical patches and discussions matter. Social media brigading - no thank you.” -Linus
Yeah, I have to issue an unqualified agreement here. Linus isn’t saying no to Rust, he’s smackin’ that ass for bringing drama out into social media instead of working through it in normal technical discussion channels.
It sounds like he tried that, and nobody with authority responded until he went outside the list. Even now, Linus hasn’t actually answered the question of whether more rust code should be allowed.
I don’t know how “whether more rust code should be allowed” is even a question. What, do you think they’re going to just cut all the rust developers off or something? Linus has always been a move slow and don’t break things kinda guy. Why should allowing rust into the kernel suddenly change that now? What is there to even answer?
Well, the rust devs are trying to add more rust code, and the dma maintainer rejected it because it was was written in rust. Thus, the question.
The dma maintainer wants all the code he’s in charge of to be stuff he likes to work with. Whether you agree with that or not, that has absolutely nothing to do with Linus Torvalds allowing more rust code in the kernel.
That’s the thing though, he’s not in charge of this code.
The lone dma maintainer isn’t in charge of the code in the dma subsystem? What do you even mean by that?
He’s not in charge of the rust code they want to merge. They asked him about it because their code talks with the dma system.
No offense, but reading through the comments it’s apparent you’re not very familiar with systems programming nor linux development. This is a common problem with vocal ‘rustaceans’, rust is their hammer regardless of the domain.
Although considering rust is prudent, there are still a ton of advantages to using C for systems programming. It is not a binary choice, there are pros and cons, and every project should choose what aligns with their priorities.
No one has ever stated that linux will be in the kernel. It was ‘go ahead and give it a shot’, which includes convincing maintainers to accept your patches. Linus has delegated trust to subsystems maintainers and an established process.
Hellwig could have been more tactful, but like it or not, arguments against a cross-language codebase have merit. Framing it as a ‘clear confession of sabotage of the r4l project’, attempting to weaponize the CoC, and trying to drum up an army via social media was all out of line.
Success was never a given, if they want r4l to succeed then they have to get patches approved and crying wolf ain’t gonna cut it.
Isn’t on of the issues on why they wanted rust is a lack of new blood in the kernel development?
Hellwig could have been more tactful, but like it or not, arguments against a cross-language codebase have merit. Framing it as a ‘clear confession of sabotage of the r4l project’, attempting to weaponize the CoC, and trying to drum up an army via social media was all out of line.
When a maintainer calls somebody’s efforts “cancer” – “spreading this cancer to core subsystems” – and that they’ll do everything they can to halt those efforts – “I will do everything I can do to stop this” – that’s as clear an indication of sabotage as you will ever get.
Sure, I saw that, too. This is Linus saying he won’t play that.
So he won’t answer on-list. He won’t respond to off-list. I don’t blame marcan for getting frustrated.
Yeah, I don’t blame him for being frustrated. I definitely empathize with him here. I don’t know about the culture around committing to the kernal, but maybe it would be better to fork and make the case with action?
Forking the Linux kernel is unlikely to go anywhere.
There is Redox, a Unix-like whole OS implemented in Rust, though I don’t know if being able to run unmodified Linux binaries is one of their goals. It looks like they’re expecting most software to be ported.
Martin seems to understand that adding a second language to the kernel is not only a technical concern, but a political one as well. Everyone else wants to pretend politics isn’t at play and that their objections are “purely technical.” They aren’t. I definitely understand Martin’s frustration here.
Shit they triggered the raid boss early
OK, who pulled?
Why am I even asking, it was the hunter of course.
LEEEEROOOOOY JENKINS!
he looks like some kind of dino, i cant figure out which one
I am so glad Linus just came out and said it. I was pretty upset at Hector too in the other thread the other day, and I especially didn’t appreciate a call to remove a major developer from the kernel because Hector wasn’t getting his way. Very militant action on Hector’s part where it just wasn’t necessary.
Hector, if you’re reading this, communication skills are just as if not more important than your Rust development skills, and frankly your communication skills lack.
I can understand their frustration, having multiple other rust for Linux project maintainers quit over nontechnical rust aversion.
And Linus continues to (democratically?) avoid the subject with this response.
As a rust for Linux volunteer you have to be incredibly demoralized reading this mess almost every other month.
Part of why linux has been a successful long term project is by making decisions conservatively. Other projects like cURL do the same. Incremental improvements over time.
It seems like there is a culture clash with the rust devs who are pushing for changes faster than the long term project maintainers are comfortable with.
So now we’ve lost a very good developer, and the question of rust in the kernel remains unresolved. This is the worst possible outcome.
The times when a single developer was important to Linux were in the 90s.
Part of being a good developer is the “working well with other human beings” part. Linus himself took a hiatus to improve himself in this area.
Another part of being a good developer is to work within and adapting to the frameworks of an existing project, especially if you are joining at a later point. In this context, it would be the R4L folks joining the project known as “the Linux kernel.”
Hector failed on both counts. He has programming skills, but that’s not all that’s required.
Sure, and part of being a good manager is to, you know, manage. It shouldn’t have gotten to the point that marcan is going outside the list to try to get something done. Linus (or someone else with authority, I’m not familiar with who else is managing it) should have stepped in much earlier to head off the drama. It was a very simple question.
Rust in the kernel is already established and part of the mainline kernel. It’s extremely pretty and wholly inappropriate to reject code just because it’s written in rust.
If you had read Christoph’s reasoning, it wasn’t “just because it’s written in Rust.” He actually gave some decent technical reasoning for it that went beyond his original personal outburst (which I hold him to the same standard as Hector for, but he did shore up later and fixed his communication).
How do you figure?
The only two “technical” arguments I could see were firstly that code should
[remain] greppable and maintainable
which unless I’m missing something boils down to “I don’t speak Rust”, and secondly that
The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
which unless I’m missing something boils down to “I don’t speak Rust”, because ain’t nobody trying to add any other languages to the Linux code base.
Surely this can’t be the “decent technical reasoning” you are referring to? I have to admit I don’t follow kernel development that closely, but I was under the impression that integrating Rust into the code base was a long discussed initiative having the “official” blessing of the higher ups among the maintainers by now, so it seems odd to see it opposed in such harsh terms by a subsystem maintainer here:
I absolutely support using Rust in new codebase, but I do not at all in Linux.
You and i read different things. I hated how he worded them, but his arguments at greppable and understandable are valid arguments that go beyond rust and if he can read it or not or refuses to.
Mixing languages in a part of a project brings complexity and is often a huge ass nono because it makes things unreadable and hard to manage on a large scale.
He also argues that a c interface exists to connect 2 parts of a system. The person that changes the interface should not have to alter the users of that interface, if they do then you get intertwined dependencies, which is a huge ass red flag for developers that something has gone terrible wrong and the project is not going to scale or will be easy to change.
So if he changes the interface, the rust team will need to fix it, specially since they are the minority.
That also doesnt mean he can change it in whatever way without worry, it is an interface change, that needs discussions and approvals ahead of time ofc.You and i read different things.
Apparently we did.
I hated how he worded them, but his arguments at greppable and understandable are valid arguments that go beyond rust and if he can read it or not or refuses to.
I’m failing to see how Rust code is not greppable unless you don’t speak Rust.
Mixing languages in a part of a project brings complexity and is often a huge ass nono because it makes things unreadable and hard to manage on a large scale.
An argument which I would acknowledge, but if the decision to do this has been made by the group it still is weird to see it blocked by an individual.
He also argues that a c interface exists to connect 2 parts of a system. The person that changes the interface should not have to alter the users of that interface, […] So if he changes the interface, the rust team will need to fix it, specially since they are the minority.
Nobody asked Hellwig to do this, in fact Krummrich said several times they would maintain the interface consuming the C code themselves. They just want one common interface for all Rust drivers, instead of replicating the same code in each driver. Which Hellwig never gives a substantial reply to.
That also doesnt mean he can change it in whatever way without worry, it is an interface change, that needs discussions and approvals ahead of time ofc.
Again not how I’m reading that thread. As Krummrich put it:
Surely you can expect maintainers of the Rust abstraction to help with integrating API changes – this isn’t different compared to driver / component maintainers helping with integrating fundamental API changes for their affected driver / component, like you’ve mentioned videobuf2-dma stuff.
Most full of shit comment in the thread
And this could also apply to all the existing devs who are fighting tooth and nail to keep rust out.
I don’t think this is the worst outcome. It would have been worse if he was the face of Rust in Linux and it died out over ten years instead of one.
That being said, hopefully it can get a fresh start.
What Rust. It’s never going to happen the old timers are fighting like hell to keepmit out.
You seem to be in the loops of the linux kernel?
If so, ive known hector from way before when we was part of f0f, or TT as they were known before, doing wii homebrew work.
What you describe is what my experience was with him 14 years ago too. The guy is smart, he has a very good skill set and knowledge, but his communication skills were lacking back then too.
Granted, both he and myself were still teenagers and students and we were wild, but i had always assumed he grew up a bit since then…What you said is spot on, and i hope he does read both of these. And if he does :
Marcan, you might not know who i am anymore, but ffs man. Dont screw up your love for all of these by keep kicking the hornets nests. You did it with devkitpro, emudevs when the nier news dropped and with rossman too. Stop it, its for your own good.and with rossman too.
I decided to read replies: wierd, they suggest accusation is overblown.
I decided to read context: WTF is this?! Unholy shit, dear Faust, what did I read? What a deflection!
I thought I was terminally online with mental disorders, but this makes me look most grass-touching and sanest person.
@semperverus Just from the small interactions I had with Hector on mastodon I can see he gets very unreasonable about small things and does not accept the possibility that he may be wrong, despite evidence. So leaving linux and mastodon because of rust is totally on brand for him.
Hector has a rap sheet of crash outs and drama.
My gut tells me that any benefits of adding Rust is massively negated by the addition of a second language.
If one wants to write Rust, there is always Redox and probably a bunch of other kernels.
I like Rust, but it’s for sure an over hyped language. In a year or two, people will push for Zig, Mojo or some new pure and polished functional low level language. Maybe a Scheme or a Lisp? That seems to be what the cool kids use nowadays.
Or maybe we’ll just replace the kernel with an AI that generates machine code according with what should be your intention.
I dunno, people have been saying Rust will go away in a year or two for, like, five years now. This feels different to me. I could easily be wrong, but I don’t think it’s just another fad language.
I’m not saying that Rust will go away.
Well, go away was maybe not exactly the correct term, but come on. You know what I meant.
My point is simply that it’s probably not worth it to add another language. Doesn’t have anything to do with Rust really.
Though I do think that the language is a bit over hyped. It’s obvious companies and projects used to say they’re using Rust, not just because they want to attract young developers or like the language, but because it’s a way to get VC. Like AI and blockchain.
I do like Rust. But mostly because it encourages functional style programming. And the tooling is of course awesome. Especially compared to C and C++. However, I do believe that static pure functional languages are superior to Rust.
C’mon man, this is just a textbook fallacious slippery slope argument. Rust isn’t some brand new language whose stable release was less than a year ago, it’s over a decade old now. Scheme and Lisp are interpreted languages for God’s sake, it’s borderline* impossible to use them for kernel programming.
Also I’m pretty sure the whole point of the Rust project that all this drama is centered around is to keep Rust code separate from the kernel. From what I understand the whole point is to maintain Rust bindings to the kernel API as a separate project, so that if developers want to write a driver in Rust, they can without having to rewrite those bindings themselves. But the kernel code itself will still be all C code. Now I’m not a kernel developer, and the last time I wrote a driver was for my operating systems class in university over a decade ago, so take that with a grain of salt.
* I say borderline because anything is possible with code if you’re creative enough, but anyone trying to submit Scheme or Lisp code to the Linux kernel is gonna get laughed off the Internet
I don’t think you get my point.
Of course I don’t mean that you should introduce Lisp or Scheme into the Linux kernel. However, I don’t rule out anything when it comes to the future of programming. Kernel programming isn’t that special. If you need to make a scheduler, dynamic memory manager or an interpreter, as part of the kernel, because it solves your problem, you do it. Maybe you want the kernel to generate thread optimised FPGA and micro code on the fly? And this is done with some kind of interpreter. Who knows.
My point is that it’s probably a bad idea introduce any new language into the kernel. A new backwards compatible version of memory safe c might be a good idea though. If it can be done.
Haven’t touched the Linux kernel in 10+ years, but my guess is that a good approach is to write a new micro kernel in Rust. One that is compatible with most existing drivers and board support packages. And of course it has to maintain the userspace ABI and POSIX yada yada. Probably what the Redox project aims for, but I don’t know.
Keeping the Rust bindings in a separate project might be unnecessary though. I’m sceptic about allowing upstream drivers written in Rust just because I find that there is such a great value in sticking to one language. I also know that many kernel developers are getting old and it gets harder to learn new languages the older you get. Especially if the language comes with a decent share of sugar and bling (the minimalism of lisp and c is valuable).
If there is a problem finding driver developers that want to write C code, then sure. But breaking the flow of the senior maintainers/developers likely isn’t worth it. Unless they ask for it.
And also, I really haven’t been following this Rust in the Linux kernel debate.
Technically there’s no such thing as a compiled or interpreted language. Python compilers exist. You could write a Scheme or Lisp compiler. Racket is a Scheme that can be interpreted or compiled
Any language containing
evalin its spec cannot be (fully) compiled ahead of time, you’ll need interpretation or JIT.Also last I checked (it’s been a while) Racket compiles to bitcode and then links in a bitcode interpreter. There’s static lisp/scheme compilers but when they come across an eval, they’re going to bail and compile in a JIT compiler or interpreter to deal with that stuff.
Fair enough, but you COULD create a compiler for a a subset of the language without eval. There are so many dialects of Scheme, what’s one without eval? Evals are very much evil anyway.
There’s plenty of schemes that aren’t fully standards-compliant but I don’t think leaving out eval is common – it’s easy to implement and nothing about the standard says that it needs to run code fast.
Just wanted to point out that eval is the real static vs dynamic boundary. As to evil, sure, you shouldn’t run just any code you find without having a sandbox in place, C’s way to do the same thing is to call
ccfollowed bydlopen, that’s way scarier, which is why people just link in lua or something instead. I guess in <currentyear> you should probably include a wasm runtime instead of usingdlopen.
