9 ms·
Torvalds: You can avoid Rust as a C maintainer, but you can't interfere with it
- Havoc 2y agoThere was always going to be some kicking and screaming on this tbh. This strikes me as a reasonable middle ground
- baq 2y agoIt's reasonable, but calling it 'middle ground' where it's purely common sense is very generous.
- deleted 2y ago[deleted]
- mort96 2y agoWell it's a middle ground between two other realistic extremes, those being "subsystem maintainers must understand and support the Rust bindings to their APIs" and "subsystem maintainers can veto the introduction of Rust bindings to their APIs".
- andrewaylett 2y agoIf anyone was seriously arguing for the former position, I've not seen it.
- mort96 2y agoI haven't seen anyone arguing for it either, but I think some maintainers are afraid that that's the direction things will evolve.
- lrsa1218 2y ago[flagged]
- bayindirh 2y agoCare to elaborate for the uninitiated?
- i80and 2y agoHow is this an ambiguous stance? "Subsystem maintainers don't have to allow Rust in, but other subsystems can and will build their own bindings to your code" seems fairly clear-cut.
- dralley 2y agoIt's made even less ambiguous by a later follow-up https://lore.kernel.org/rust-for-linux/2cbxfvvsau5sobm3zo5ds7u26jeiskxs6cavp5a7hbokjisobi@2ybqbl6iry6k/T/#m5df8c08f98e113d6e5e8401839182ffaa8433e12 https://lore.kernel.org/rust-for-linux/2cbxfvvsau5sobm3zo5ds...
- blueflow 2y agoAre you displeased with Linus' leadership because he make the decision you want him to make?
- ykonstant 2y agoThere is nothing ambiguous here, if anything Torvalds is simply enforcing common sense: Rust devs cannot be divas, and C devs cannot be saboteurs. If anything, the whole kerfuffle is astounding for the lack of common sense, and sense of camaraderie, among those kernel devs. It should not take a dictator to enforce the obvious, but in this case it seems like it does.
- homarp 2y agoprevious discussion https://news.ycombinator.com/item?id=43123104 https://news.ycombinator.com/item?id=43123104
- zubspace 2y agoIt's an interesting discussion. There's always a divide when you slowly migrate from one thing to another. What makes this interesting is that the difference between C code an Rust code is not something you can just ignore. You will lose developers who simply don't want or can spend the time to get into the intricacies of a new language. And you will temporarily have a codebase where 2 worlds collide. I wonder how in retrospect they will think about the decisions they made today.
- bayindirh 2y agoI don't think changing to Rust code completely is something attainable. I guess some older or more closer to the metal parts will stay in C, but parts seeing more traffic and evolution will be more rusty after some time, and both will have its uses and have their islands inside the codebase. gccrs will allow the whole thing to be built with GCC toolchain in a single swoop. If banks are still using COBOL and FORTRAN here and there, this will be the most probable possibility in my eyes.
- leonheld 2y ago> I guess some older or more closer to the metal parts will stay in C I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things. This reminds me I need to do some non-trivial embedded project with Rust to see how it behaves in that regard. I'm not sure if the abstraction gets in the way.
- bayindirh 2y agoAfter writing some non-trivial and performance sensitive C/C++ code, you have feeling of how that code behave on the real metal. I have that kind of intuition, for example. I never had to dive to the level of generated ASM, but I can get ~80% of theoretical IPC with just minding what I'm doing in C++ (minimum branching, biasing branches towards a certain side, etc.). So, I think if you do the same thing with Rust, you'll have that intuition, as well. I have a friend who writes embedded Rust, and he said it's not as smooth as C, yet. I think Rust has finished the first 90% of its maturing, and has the other 90%.
- z0ltan 2y ago[dead]
- Muromec 2y agoYou can see that Linus actually makes an effort to be at least somewhat nice nowdays, while still sticking to pragmatic technical decisions.
- p0w3n3d 2y ago> to be at least somewhat nice nowadays That's a huge sacrifice when speaking of him, which we must appreciate. But to be honest, I must agree with his point of view. Golden rule when developing projects is to stick to one (the least amount possible of) technology, otherwise, you'll end up with software for which you need to hire developers of different languages or accept the developers that won't be experts in some of them. I am working on a project that, up until a year ago, had been partly written in Scala. All the Java developers who didn't know Scala were doomed to either learn it in pain (on errors and mistakes) or just ignore tasks regarding that part of the system.
- lambdaone 2y agoYou're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex, and C so obviously outdated now, that it's worth the pain to start writing drivers in Rust. And because of the modularity of the kernel, and the care taken to make Rust binary-compatible with C, this looks to be actually practical, as individual subsystems will be either entirely Rust or entirely C, particularly when new drivers are involved.
- Joel_Mckay 2y ago[flagged]
- tremon 2y agoPolyglot projects by their very nature inject unstable dependencies into the build tree What does this mean? This also make the core feature of bootstrapping Linux on new hardware more difficult. If by this you mean that Rust doesn't support all the architectures that gcc does: - that didn't stop people from making sure Linux could be compiled with LLVM as well - gccrs should make this issue moot anyway, as that will allow Rust code to be emitted for exactly the same architectures as gcc proper
- jvillasante 2y ago[flagged]
- perching_aix 2y ago[flagged]
- tmountain 2y agoFor what?
- fransje26 2y agoFor the world servers and supercomputers to run on Windows.... /s
- perching_aix 2y agoWe can also just keep them powered off you know, it's still not too late :)
- perching_aix 2y agoFor [flagged], obviously.
- cosmicradiance 2y agoWho's taking the baton?
- knowknow 2y agoIn what way?
- high_na_euv 2y ago>We've turned our development model into a well-oiled engineering marvel Especially those mailing list, engineering marvel, indeed!
- timeon 2y agoWhat is wrong with that?
- high_na_euv 2y agoHard to read, lack of syntax highlighting, annoying to participate
- macspoofing 2y agoAs a C maintainer, you should care how the other side of the interface is implemented even if you're not actively involved in writing that code. I don't think it is reasonable, for software quality reasons, to have a policy where a maintainer can simply pretend the other side doesn't exist.
- dralley 2y agoSure, and that's ideal for the maintainers that are willing to do that (and there are several), but for the C devs that just don't care and can't be forced to care, this is a pragmatic compromise. Not everyone has to be involved on both sides.
- macspoofing 2y ago>this is a pragmatic compromise. Yes. This is exactly what it is. It is a "pragmatic compromise" to side-step major internal cultural and philosophical issues (not technical issues). You're basically telling a number of C maintainers that they can simply pretend Rust doesn't exist, even if it may be the case that Rust code is the primary consumer of that API. That's a workable solution, but it isn't an ideal solution - and that's a little sad.
- bena 2y agoYou should care that it is usable, but how they use it should not concern you. If someone wants to use the usb driver to interface with a coin motor to build vibrating underwear, then that's none of your business. Your concern is if your driver works to spec and can be interfaced. So if someone wants to write software in Rust that just uses the DMA driver, that should be fine. Linus is entirely in the right.
- renewedrebecca 2y ago> If someone wants to use the usb driver to interface with a coin motor to build vibrating underwear starts writing business plan while installing CMake
- 2y ago
- evanjrowley 2y agoLinus said that non-rustacean C programmers cannot veto rust code, but he did not clearly state how it works going the opposite way. It was rustacean-proposed changes on the C side that led to this drama. I don't see much progress here.
- Diggsey 2y agoI don't think that's accurate. It was adding Rust DMA code that was to be shared between Rust drivers that was the spark. The C code was unchanged AFAIK.
- dralley 2y agoThe patches did not touch the C side whatsoever, a fact that Linus was pretty vocal about in his berating.
- timeon 2y ago> It was rustacean-proposed changes on the C side that led to this drama. Why would you say something like that? From the e-mail [0] the article is based on: > The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. > It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form. [0]: https://lkml.org/lkml/2025/2/20/2066 https://lkml.org/lkml/2025/2/20/2066
- monideas 2y agoDirect link to Linus' email: https://lkml.org/lkml/2025/2/20/2066 https://lkml.org/lkml/2025/2/20/2066
- glitchc 2y agoI can see only one viable path for Rust folks: Fork the kernel and make whatever mods are needed. It's not Linux anymore, but that's how Linux started from Unix all those years ago.
- thfuran 2y agoWhy do you see "not written in rust" as fundamental to the identity of the Linux kernel?
- glitchc 2y agoWhat the Rust community is trying to do is antithetical to the whole free software movement. They want to impose a new language onto an existing body of maintainers who have limited incentives to change. The "free" part in free software is not just free in beer, it's also free in freedom. That little bit gets forgotten. People work on it because they want to, not because they have to. If a developer does not want to use Rust, they can and should not be forced to. It does not matter if Rust is objectively safer, or better, or any of the purported arguments. Forcing it eliminates the freedom of choice. The Rust folks should make their own kernel and OS. Let it compete directly with Linux. In open source, this is the way.
- bryanlarsen 2y agoSince Con Kolivas resigned in 2007 there have been no volunteers making major contributions to the Linux kernel. Everybody is doing it as a job. So they are working on it because they have to, assuming they want to continue to get paid.
- steveklabnik 2y ago> They want to impose a new language onto an existing body of maintainers "The Rust folks" are part of that existing body of maintainers, not some outside force.
- imtringued 2y agoWhat you've said has nothing to do with free software. "Freedom" doesn't mean freedom from Rust, for starters.
- SeanLuke 2y agoI get the feeling that, no matter how slow Linus goes, this is going to lead to a split. If Linus eventually pushes through Rust, the old guard will fork to a C-only version, and that won't be good.
- bryanlarsen 2y agoSeems highly unlikely. Note that Hellwig is the only major remaining independent Linux kernel developer. All the rest have salaries paid by the Linux Foundation, Red Hat, Google, et cetera. They are highly unlikely to take an action that threatens their salary. And Hellwig works as a contractor, he's not a volunteer in the same way that Con Kolivas was. Hellwig isn't truly independent either.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- 1vuio0pswjnm7 2y agoWhat does this mean for kernel compilation times and toolchain requirements
- vdfs 2y agoNothing new, kernel already use rust in same parts
- spintin 2y ago[dead]