29 ms·

> I thought Linux was C only It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linus-torvalds-predicts/ https://thenewstack.i

> I thought Linux was C only It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linus-torvalds-predicts/ https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linu... . But I don't expect C++ to be added.

cesarb 4y ago
> > I thought Linux was C only > It won't be for long (Rust) To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).
ActorNightly 4y ago
Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust. While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.
- tialaramex 4y ago
  > Its the same reason why C++ hasn't been adopted. Among the reasons C++ hasn't been adopted for Linux: * Nobody actually did the hard work. The Rust for Linux people have spent a lot of time actually making this possible. C++ proponents tend to just drive past "Ha, you should use C++" which they presumably think makes them seem clever but it doesn't. * C++ doesn't have a coherent "freestanding" subset. In theory (and according to the ISO document) there's freestanding C++ but in practice you quickly find you need lots of custom runtime stuff, it's not really part of the C++ standard at all. * Linus is trying not to be an asshole and that's not going to be helped by introducing a C++ culture where you'll routinely see sentiments like "This has a Code of Conduct so it's for fucking snowflakes". * C++ loves implicit allocation and Linus hates implicit allocation, especially infallible allocation. Now, you could sort of fix this if you rewrote a lot of stuff, and indeed in the Rust for Linux implementation of alloc (Rust's allocation library) there are a lot of places where it does fallible allocation and doesn't offer implicit allocation. The example of the latter which won't affect most kernel programmers but I think is easiest for a typical programmer to understand is this: In C++ or Rust, if I have a string called adjective (maybe it's "Fast") and a string called noun (maybe "Cheese", and I write phrase = adjective + noun; then we're going to get the resulting word from concatenating the two strings ("FastCheese"), right? Is this abuse of the + operator? Maybe. But it works. In Rust for Linux that won't compile. Because it's an implied, infallible allocation. To put that concatenated string somewhere there's an allocation, which could fail, and how could the + operator "fail" ? Where does the error go if this happens?

cesarb 4y ago

> > I thought Linux was C only > It won't be for long (Rust) To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).

ActorNightly 4y ago

Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust. While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.

tialaramex 4y ago
> Its the same reason why C++ hasn't been adopted. Among the reasons C++ hasn't been adopted for Linux: * Nobody actually did the hard work. The Rust for Linux people have spent a lot of time actually making this possible. C++ proponents tend to just drive past "Ha, you should use C++" which they presumably think makes them seem clever but it doesn't. * C++ doesn't have a coherent "freestanding" subset. In theory (and according to the ISO document) there's freestanding C++ but in practice you quickly find you need lots of custom runtime stuff, it's not really part of the C++ standard at all. * Linus is trying not to be an asshole and that's not going to be helped by introducing a C++ culture where you'll routinely see sentiments like "This has a Code of Conduct so it's for fucking snowflakes". * C++ loves implicit allocation and Linus hates implicit allocation, especially infallible allocation. Now, you could sort of fix this if you rewrote a lot of stuff, and indeed in the Rust for Linux implementation of alloc (Rust's allocation library) there are a lot of places where it does fallible allocation and doesn't offer implicit allocation. The example of the latter which won't affect most kernel programmers but I think is easiest for a typical programmer to understand is this: In C++ or Rust, if I have a string called adjective (maybe it's "Fast") and a string called noun (maybe "Cheese", and I write phrase = adjective + noun; then we're going to get the resulting word from concatenating the two strings ("FastCheese"), right? Is this abuse of the + operator? Maybe. But it works. In Rust for Linux that won't compile. Because it's an implied, infallible allocation. To put that concatenated string somewhere there's an allocation, which could fail, and how could the + operator "fail" ? Where does the error go if this happens?