Well - of course I prefer a centralized package manager like pacman, which I also use for python packages etc., but I mainly dislike the building process of rust, which is usually done with cargo. No libraries, not even a global cache for already compiled dependencies, no distcc. This makes it infinitely slower than most C/C++ projects. Compiling the kernel is literally faster than compiling a “simple” project like spotify_cli (500+ dependencies, depending on configuration).
So it’s ass from a user perspective, waiting for stuff to compile (just for it to fail, and start from scratch, as some stuff needs a clean build/src dir), and imo very weird from a dev perspective.
Did he actually say that he likes it? My impression was that it’s not his comfort zone, but he recognizes that for the vast majority of young programmers, C is not their comfort zone. And so, if they don’t hop on this Rust train, the Linux kernel is going to look like a COBOL project in a not too distant future. It does not happen very often that a programming language capable of implementing kernels gains wide-spread adoption.
If they can define a useful ABI that manages to include lifetimes, that might just be enough of an improvement to get people to switch over from assuming the C ABI everywhere.
The problem is that both Rust and Go are huge. The compiled binaries are bigger and the compilers themselves and slower and more resource intensive. The current benefit to C is that is lean and compiles quickly.
Rust is only huge because it doesn’t have an ABI. If you had an ABI (and didn’t have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they’re only slightly bigger than a C counterpart
Edit: I don’t know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it.
Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with “I’m tired of paying for an ABI stability I’m not using” it’s not so clear it would really be a boon to Rust.
That said no_std appears to be what people go to for the lean Rust.
And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It’s part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it.
The cool kids are forcing people to read this at gunpoint nowadays
I’ll never touch Rust.
I hate the syntax and cargo too much for that. If that means that I’ll never write mission critical, low level code, so be it.
What don’t you like about Cargo? Is there another package manager you like more?
Well - of course I prefer a centralized package manager like pacman, which I also use for python packages etc., but I mainly dislike the building process of rust, which is usually done with cargo. No libraries, not even a global cache for already compiled dependencies, no distcc. This makes it infinitely slower than most C/C++ projects. Compiling the kernel is literally faster than compiling a “simple” project like spotify_cli (500+ dependencies, depending on configuration).
So it’s ass from a user perspective, waiting for stuff to compile (just for it to fail, and start from scratch, as some stuff needs a clean build/src dir), and imo very weird from a dev perspective.
Right? It’s in the kernel and everything now. Linus likes it. Linus hates everything. HOW MUCH ARE THEY PAYING HIM?
Big Rust has gotten to Linus
Not the L man!
One (1) good programming language is what they paid him XD
Did he actually say that he likes it? My impression was that it’s not his comfort zone, but he recognizes that for the vast majority of young programmers, C is not their comfort zone. And so, if they don’t hop on this Rust train, the Linux kernel is going to look like a COBOL project in a not too distant future. It does not happen very often that a programming language capable of implementing kernels gains wide-spread adoption.
Why is there Gleam and Deno on the cover?
I know you’re joking, but uh, both of those are (largely) implemented in Rust…
Cool, I didn’t know that!
I like Go better
However, C is still king in a lot of ways
C is definitely still king, but I wonder if crABI will eventually be able to dethrone it:
https://github.com/rust-lang/rust/issues/111423
If they can define a useful ABI that manages to include lifetimes, that might just be enough of an improvement to get people to switch over from assuming the C ABI everywhere.
The problem is that both Rust and Go are huge. The compiled binaries are bigger and the compilers themselves and slower and more resource intensive. The current benefit to C is that is lean and compiles quickly.
Rust is only huge because it doesn’t have an ABI. If you had an ABI (and didn’t have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they’re only slightly bigger than a C counterpart
Edit: I don’t know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it.
Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with “I’m tired of paying for an ABI stability I’m not using” it’s not so clear it would really be a boon to Rust.
That said
no_stdappears to be what people go to for the lean Rust.And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It’s part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it.