4 ms·

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 fo

by throwaway2037 2y 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.

hinkley 2y ago
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?
- pornel 2y ago
  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.
  - matu3ba 2y ago
    > 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 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.
    - pornel 2y ago
      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 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++.
      - matu3ba 2y ago
        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.
  - jandrewrogers 2y ago
    > We don't have a Rust-killer language yet. We don't even have a C++ killer language yet. These things move very slowly.
- throwaway2037 2y ago
  > 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?
Gibbon1 2y ago
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.
- jack_pp 2y ago
  I guess you make a living writing zero day exploits?
  - Gibbon1 2y ago
    Keep believing that Rust magically prevents you from getting owned when you fuck up.
    - WesolyKubeczek 2y ago
      Still owns you, but without data races!
    - _ph_ 2y ago
      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.
      - uecker 2y ago

hinkley 2y ago

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?

pornel 2y ago
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.
- matu3ba 2y ago
  > 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 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.
  - pornel 2y ago
    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 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++.
    - matu3ba 2y ago
      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.
- jandrewrogers 2y ago
  > We don't have a Rust-killer language yet. We don't even have a C++ killer language yet. These things move very slowly.
throwaway2037 2y ago
> 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?

Gibbon1 2y ago

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.

jack_pp 2y ago
I guess you make a living writing zero day exploits?
- Gibbon1 2y ago
  Keep believing that Rust magically prevents you from getting owned when you fuck up.
  - WesolyKubeczek 2y ago
    Still owns you, but without data races!
  - _ph_ 2y ago
    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.
    - uecker 2y ago