It really does seem like there's some old-guard who are utterly determined to now allow this to happen. That's not to say that Rust is inevitable in the kernel, but they're refusing to even allow the attempt. The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.<p>In addition, the changes needed on the C side for RiL are needed anyways! Lifetimes aren't just a Rust thing, it just makes them forefront. You still need to keep track of them in C, and so they need to be documented since the language sure isn't going to help you. Refusing to document them isn't just harming Rust in Linux, it's harming the long-term viability of Linux in general. When the current maintainers quit, who's going to be able to untangle all that? Bug fixes still need to happen if they're only discovered because someone tried to formalize your interface!
Things like this remind me of Planck's principle:<p>> A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it<p>It's interesting to hear the complaint is "you can't make me learn another language" from someone like Ted Tso. Learning your 2nd language is very hard but at some point it becomes routine, especially since a good chunk of these languages are all Algol-based in some sense. And the main "new" thing is different concepts like functional ways to write programs and various other ergonomic improvements. But really those things just make your code clearer.<p><a href="https://en.wikipedia.org/wiki/Planck%27s_principle" rel="nofollow">https://en.wikipedia.org/wiki/Planck%27s_principle</a>
I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome.<p>I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.
I think we need to consider the perspective of the linux maintainers.<p>Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on.<p>I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work. You need to convince them to <i>want</i> to do the work. Doing this shouldn't be dismissed as nontechnical nonsense... it's a very significant hurdle, and one that's directly on the critical path.<p>BTW, naming and shaming and internet pitchforks are guaranteed to make people <i>not</i> want to do the work, so unless you actually want to kill rust-in-linux, you might want to shut that down.<p>(Also, I wonder if there isn't a better way to bring memory-safety to the linux kernel. One that is just as effective as rust but less disruptive. The hostile us-vs-them dynamic building up around RiL might torpedo the whole thing, so it might be worth looking for effective alternatives.)
As a casual Rust user, I feel it’s a bit ridiculous to think something could outdo Linux only by choice of programming language. Is that the “nontechnical nonsense” here?
I wish OSS projects had way less drama.<p>Rust for Linux had great potential, and would have been a cool alternative to the existing C driven model.<p>At least eBPF has diverse corporate sponsorship, so drama is somewhat tempered.<p>Would be great if more companies pitched in to help the FOSS ecosystem, otherwise the only option is an Open Core model.
For me, this discussion won't lead anywhere because it covers the wrong topic.<p>It's not about Rust or C - it's about transparency. The existing maintainers assume that it is not a priority for them whether they break something downstream or not. They therefore work in a space with interfaces that they can change as they see fit, without giving any guarantees as to their continued existence or wanting to subordinate themselves to a defined change process.<p>Rust is just a symptom of growing pains. Growth would be achieved if they could agree on common rules which would foster independent development linked by the interface contracts.<p>Instead, the issue is that established maintainers have grown fond of their zoo and are only pursuing their own priorities in a landlord-like manner. On the other hand, they see new technologies appearing and disappearing on the horizon and have consequently realized that a new technology or language cannot improve an existing system.<p>And yet they are classically talking past each other.