Hacker News Reader

Comment by throwaway2037 | Hacker News Reader

throwaway2037

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.

View on HN

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.

There was also Cyclone before Rust, and Checked-C in the meantime. The concepts like regions and affine types existed long before Rust, and Rust started out by copying from older languages (http://venge.net/graydon/talks/intro-talk-2.pdf).

It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.

Yes, I do agree with you. Just wanted to inform you that it may still be possible in principle and as you can see with development speed, build system, dependencies etc there is a potential angle.

> We don't have a Rust-killer language yet.

We don't even have a C++ killer language yet. These things move very slowly.

    > If you wait long enough a Rust competitor will gain traction.

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.

That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.

Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.

Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?

Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.

Is it trivial to audit? Here is a critical overflow in a matrix transpose: https://vulert.com/vuln-db/crates-io-transpose-125781

This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.

It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code. I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.

The example shows that Rust can not even prevent an error as something simple as in a matrix transpose. Sure, you could write safe code, but how does this help if people don't do it? It is the exact same problem as in C and I have seen C code that is very reasonable.

Do you have a link to the code with the error? Following your link I didn't see it.

This is a better link which then has a link to the Github issues: https://rustsec.org/advisories/RUSTSEC-2023-0080

Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.

My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.

Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.

I think this is exactly the life lie of Rust. It claims to be memory safe and equally suited for system programming. But you get memory safety only when completely avoiding unsafe and it competes with C only when using unsafe. And it is certainly not true that you get memory safety in the part not using unsafe or that you only need to review the unsafe part. The memory safety of the safe part depends on the programmer maintaining invariances in the unsafe part that the Rust compilers needs to ensure the memory safety. At the same time the safety prerequisites of the unsafe parts can be violated by logic errors in the safe part (as in the transpose examples). It still helps to isolate the unsafe part, but in practice I am not convinced that the typical Rust code I see for system programming is fundamentally more secure than equally well designed C code which was also written with an eye towards memory safety and with use of modern tools to find problems.

Still owns you, but without data races!

> 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.

Reply on news.ycombinator.com