[uv-depression]

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.

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!

[fsckboy]

>It really does seem like there's some old-guard who are utterly determined to now allow this to happen.

unices and then into the linux project have been a massively successful series of massive C library/API/threading/timing/bittwiddling coordination efforts.

some people now want to turn that Ship of Theseus into catamaran, while it's sailing? Rust people could probably more easily just use the Linux sources and rewrite it into a new better system, clean effort.

Coordinating people is time consuming and difficult, and this "project" clearly makes that issue a lot worse in the interim phases. Seems downright Bayesian, if you know what I mean.

[bluGill]

Anybody can write a good kernel for one single computer (not just CPU) in a couple years. What makes linux useful is the vast amount of different hardware combinations it supports, often with "black magic" because some hardware doesn't work unless you do something weird (commonly you have to wait some amount of time after the power comes on before using it). One computer is easy, adding support for a second that is even slightly different is more work. Linux works correctly on millions of combinations by now (most of those combinations have not been tested but they would work)

[bitexploder]

Linux is like 27 million lines of code. The core is several million.

I think efforts like gVisor and other sandboxing technologies are the future. gVisor and friends like it can minimize the attack surface of unsafe code down to some minimum.

Rust in Linux as an experiment should go on. Core functionality can likely be re-implemented in Rust and continue to get some meaningful % of the critical path of code safer, but there will always be some level of "unsafe" code in an operating system kernel.

[znpy]

Indeed, I have a similar feeling.

"Rust people" are annoying because they largely want their stuff upstreamed, and they want it NOW. If you have any form of doubt they'll call you names and mark your word as nonsense. It's just obnoxious.

It's okay to want changes, and I think Rust in Linux is a great thing, but you can't expect people to just drop off everything and give you all the attention you want in the exact specific way you want it, and to give all that attention TODAY.

Otherwise just go ahead, fork Linux and do your thing... If it's any good Linux will pull and merge the changes.

[0xcde4c3db]

> The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.

I don't think most of it is bad-faith argumentation so much as a failure to assume good faith. This is mostly conjecture on my part (I've only read a small percentage of the LKML and Mastodon threads about this stuff), but I think the idea is pretty straightforward:

Rust trains developers to think about lifetimes, locks, race conditions etc. in pretty specific ways, learn the language of borrow checker errors, and so on. People who haven't written a lot of both Rust and C simply won't have the particular mindset and skill set to look at any given "Rust problem" and understand how it could map to a shortcoming in the C code it's wrapping. So when a Rust developer is trying to wrap a C API and discovers an issue, I think the C-only developer taking the report/patch is primed to see not an indication of a legitimate bug, but rather an attempt to force C code to conform to Rust semantics, for the sake of simplifying the Rust developer's job. The Rust developer tries to explain, but this comes across as an irrelevant appeal to some obscure theoretical concern. At this point, further objections are obviously just the Rust developer being lazy, stubborn, doctrinaire, and otherwise not cut out for kernel development. Something like this probably only needs to happen a handful of times to mutate into a fairly durable meme of "Jesus fucking Christ, these Rust evangelists are exhausting. What the fuck is wrong with them?".

[generalizations]

> amount of bad-faith argumentation happening

From my position as an observer, Rust proponents need to deal with their own zealots before they can get annoyed with Linux kernel old-guard for being stubborn.

[minkles]

I think the nature of the problem is the other way around. This is not harming the long-term viability of Linux. It is harming the long-term viability of Rust. As a systems programming language, the promise of which was using it to write secure kernel and system code, not being accepted into a mainstream OS kernel on either technical or political merit is a death sentence.

Both perspectives need to be tested against each other, carefully.

[jenadine]

Code is docs. One can just infer lifetime by reading the code.

(That said, having it encoded in the type system makes it many times easier)

[jsheard]

Asahi Lina posted a thread about how difficult this actually is in practice:

https://threadreaderapp.com/thread/1829852697107055047.html

[p1necone]

> One can just infer lifetime by reading the code.

For trivial cases sure, for complex ones though this is akin to saying "you can know if there's any bugs by reading the code" which we all know is not true for any reasonable time investment put into reading the code.

[_dain_]

>One can just infer lifetime by reading the code.

Enormously load-bearing "just" there. And if there's a subtle lifetime bug ... ?

[Tyrannosaur]

Pretty sure I can get close to mapping that to solving the halting problem

[amluto]

Have you actually looked at Linux device model code? Or filesystem code? Or most other code? Most is poorly documented. Most is overcomplicated. Quite a bit is flat-out wrong.

[saagarjha]

One can just write correct code, of course.

[bluGill]

Sure you can, particularly in simple cases. However some code needs years to understand because something seemingly unrelated happening elsewhere changes things. The kernel often has to run on several different CPUs at the same time, and shouldn't sync the CPU caches if it is possible to avoid it.