514
One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"
(www.phoronix.com)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
There's always going to be pushback on new ideas. He's basically asking people questions like "Hey how does your thing work? I want to write it in rust." and gets the answer "I'm not going to learn rust.".
I think rust is generally a good thing and with a good amount of tests to enforce behavior it's possible to a functionally equivalent copy of the current code with no memory issues in future maintenance of it. Rewriting things in rust will also force people to clarify the behavior and all possible theoretical paths a software can take.
I'm not gonna lie though, if I would have worked on software for 20 years and people would introduce component that's written in another language my first reaction would be "this feels like a bad idea and doesn't seem necessary".
I really hope that the kernel starts taking rust seriously, it's a great tool and I think it's way easier to write correct code in rust than C. C is simple but lacks the guardrails of modern languages which rust has.
The process of moving to rust is happening but it's going to take a really long time. It's a timescale current maintainers don't really need to worry about since they'll be retired anyway.
From a developer standpoint you're taking someone's baby, cloning it into a language they don't understand and deprecating the original. Worse, if you're not actually interested in taking over the project you've now made it abandonware because the original developer lost heart and the person looking for commit counts on GitHub has moved on.
Obviously these extremes don't always apply, but a lot of open source relies on people taking a personal interest. If you destroy that, you might just destroy the project.
I apologize if this is more nontechnical nonsense as Im not a coder, but if the projects are open source, cant he just read and translate the code?
For the same reason spoken languages often have semantic structures that make a literal translation often cumbersome and incorrect, translating nontrivial code from one language into another without being a near expert in both langauges, as well as being an expert in the project in question, can lead to differences in behaviour varying from "it crashes and takes down the OS with it", to "it performs worse".
I'll add that even when you're an expert in both languages, it's common to see WTF's in the original and not be sure if something is a bug or just weird behavior that's now expected. Especially when going from a looser to a more strict language.
I've translated huge projects and most of the risk is in "you know the original would do the wrong thing in these x circumstances -- I'm pretty sure that's not on purpose but.... Maybe? Or maybe now someone depends on it being wrong like this?"
Even if you wrote the code yourself you can come back to it a while later and have a wtf moment ¯\_(ツ)_/¯
Also, even if you think it's a bug it might be a feature that other people use and "fixing" changing it might break systems.