they wanted to change the semantics of struct inode to be rust-ified
No, they wanted to encode the current semantics in Rust. The example shown was a version based off how ext2 works. If you rewatch the presentation you will here how Wedson says that what he was showing was just an example and he was willing to change it to better match its actual semantics as it is used among the various filesystems of Linux.
Both Al Viro and Ted 'tso sounded quite reasonable and not too confrontational.
"Here's the thing, you are not going to force all of us to learn rust." It sounded confrontational to me, and sounded like something defensively said to just shut down Rust in Linux as opposed to a good faith argument since no one was claiming that everyone needed to learn Rust.
At the start of the presentation, the presenter (and one guy from the audience??) shill Rust as a superior way to encode the filesystem interfaces. Honestly, if I were in the position of shilling my stupid hype language in a project that was built for 30 years in another one, I'd keep my head down and integrate as close to the existing interfaces as possible.
That "guy from the audience", is the primary developer of bcachefs, a filesystem kernel developer. Creating proper Rust bindings and maintaining them will take work and to motivate people to do the work there needs to be some pay off. The point of hyping up Rust and explaining how it improves the developer experience and saves time is meant to show that there is value in doing such work. Even if they wrote a FFI functions that just did things exactly the C way it still requires understanding what semantics exist in the C code. I've happened to already have written a Linux filesystem in Rust before without the Rust For Linux fork and I can say that you will end up running into the same exact problems in your filesystem code that would exist in such bindings. Having all of this get encoded at the bindings layer makes it easier to maintain and easier for people to develop against since they do not have to figure out everything themselves.
Because every tiny change to the way the API behaves is reflected in it
If your change is big enough to change the semantics of how the API works, then I wouldn't call it a tiny change as you have to very carefully inspect every single place that uses it to make sure it still is being used correctly.
Instead of trying to convince everybody that Rust will magically fix everything
Rust was not advertised as a silver bullet.
No one likes people that drop a large amount of code and then simply abandons it because of a retarded tantrum where people disagreed on how to do something.
Maintainers can step down. And that code is not abandoned. There are still 2 others and 6 reviewers for general Rust in Linux listed in the MAINTAINERS file. Improvements for Rust are still be submitted to the mailing list. Fighting an uphill battle in getting changes through is time consuming and draining. It is not to fair to say that he had a "retarded tantrum."
* Panicking whenever something goes wrong is a dumb thing to do outside of userspace
I have seen fail fast design work effectively when developing operating systems and prioritizes things to actually get fixed instead of letting some warning logs that get ignored forever. It may be different then avoiding failure at all costs, but it is not dumb.
* Panicking when you can't allocate memory is definitely a dumb thing to do outside of userspace
Rust for Linux uses it's own allocator and it does not panic when failing to allocate memory. Functions that do allocation can return an AllocError.
* There's no Rust standard
It is being worked on. You can read the current version at
https://doc.rust-lang.org/reference/introduction.html.
* There's only one Rust compiler, and the community autistically screeches whenever someone tries to create another
That "one" compiler has several official backends: LLVM, GCC, and Cranelift. And despite whatever "screeching" that may be happening from the peanut gallery other frontends like gccrs are being worked one.
* Linux supports more architectures than Rust does
The gcc backend can be used to target those architectures.
* Rust takes longer to write than C, even with competent developers ("struggling with the borrow checker", etc.)
Even if that was true, Rust will save developer time after writing since it will reduce bugs and reduce complexity with better abstractions and architecture. Competent developers should not struggle with the borrow checker as it is just enforcing lifetimes that developers would have had to keep track of and enforce themselves. It shows a compiler error immediately instead of it manifesting as a bug in the future.
* The npm-ness of Cargo is a left-pad disaster waiting to happen
Crates when yanked are still able to be downloaded which prevents the left-pad disaster from happening.
* The inherent nature of kernel code means a lot of it is going to be unsafe, removing a lot of Rust's benefits
Safe abstractions can be built on top of unsafe code.
* It'd take literally man-millennia to rewrite all of Linux in Rust, and nobody wants to pay for that
Success of Rust For Linux is not that the entire kernel is rewritten in Rust. The ability for new kernel modules to be built faster, have better security, and have less bugs will be beneficial to Linux. It will be up to the maintainers of subsystems to evaluate if rewriting in Rust makes sense.
the lack of successful big Rust projects proving its viability is a testament to its unwieldiness.
A lot of successful projects were started many years or even decades ago, before Rust was in a state where it would be worth writing the whole project in. Now that Rust has reached an inflection point many projects and companies are adopting it in at least limited form. Many existing successful projects are now starting to adopt Rust code and libraries: Windows, Linux, Android, Chrome, Firefox, etc due to the benefits it offers over using C++. There are plenty of smaller successful rust projects like web developer tools, ruffle (flash player replacent), or ripgrep (bundled with vscode for code search).
because developers will be forced to bypass many of Rust's built-in safeguards to implement low level functionality
Most code does not need to bypass these safeguards. And safe abstractions can be built around unsafe code to make it safe to use.
the compiler will continue to be an impediment forcing developers to do things the "Rust way."
What is the Rust way? Forcing people to not write use after frees? I don't think it's bad to force people to not write buggy code.
