Comment by throwaway2037
10 months ago
Can I ask something controversial? What if Rust never becomes a significant part of the Linux kernel? What if they keep stalling and all the people pushing for it give up? There seems to be this faith on HN that Rust absolutely belongs in the Linux kernel and if not, the project is a failure.
If you wait long enough a Rust competitor will gain traction. And honestly I wonder if that might not be for the best. How many of rust’s features have only been tried a couple of times?
The Rust project started 15 years ago, and spent a decade growing userbase, library ecosystem, and proving that it's a serious language that's here to stay (which some C maintainers still don't believe).
We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.
Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.
> We don't have a Rust-killer language yet.
The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.
Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.
> Zig went in a different direction.
There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.
Correct me, if wrong etc.
2 replies →
> We don't have a Rust-killer language yet.
We don't even have a C++ killer language yet. These things move very slowly.
Are you implying that a fork of the Linux kernel will win? I doubt it. The Linux kernel is over 30 years old and has resisted multiple attempts to fork. In all cases, it was the winner. What is different this time?
My thought is what's telling is the 'rewrite it in rust'. Rust doesn't have a new business case.
C was better than assembly. C++ was better than C for GUI applications. JAVA has garbage collection and usually won't force you to fix your machine after a bad crash. Python is better than Perl for quick and dirty stuff. PHP lets you build a web service without much pain. C# is a better Java that also gives you better integration with Windows. Go does a good job with small quick running services. Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
I guess you make a living writing zero day exploits?
Keep believing that Rust magically prevents you from getting owned when you fuck up.
11 replies →
> Go codebases? Switching to Rust so you can what exactly?
The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.
but those improvements, and the complexity that they bring, are not enough to make the switch from a Go codebase to a Rust codebase unless performance is REALLY an issue.