4 ms·

He also said that most of the issues with writing kernels have nothing to do with choice of programming language, but instead hardware compatibility. Neither Ru

He also said that most of the issues with writing kernels have nothing to do with choice of programming language, but instead hardware compatibility. Neither Rust nor anything else could help this.

ajxs 7y ago
Here's the source of the original quote: https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-... Admittedly, kernel and driver development are different things. The original quote was to do with kernel development. "That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations. ...I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed." I disagree with him about Ada, for what it's worth, but the overall point is correct. The real problems of kernel development aren't things a borrow checker will help with. A big part of developing a kernel takes place before management of heap memory is even relevant. All this being said. For user-space applications, Rust has a lot to offer.
- swfsql 7y ago
  I read that slightly differently. I read that as: "even after putting the shoes on, the marathon still needs to be run". So yes, lifting reasoning burden away from eg. function interfaces (owning vs uniquely borrowing vs shared borrowing), lifetime problems (and so on), precisely enables everyone to put/spend more "effort" on the remaining difficulties.

He also said that most of the issues with writing kernels have nothing to do with choice of programming language, but instead hardware compatibility. Neither Rust nor anything else could help this.

ajxs 7y ago

Here's the source of the original quote: https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-... Admittedly, kernel and driver development are different things. The original quote was to do with kernel development. "That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations. ...I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed." I disagree with him about Ada, for what it's worth, but the overall point is correct. The real problems of kernel development aren't things a borrow checker will help with. A big part of developing a kernel takes place before management of heap memory is even relevant. All this being said. For user-space applications, Rust has a lot to offer.

swfsql 7y ago
I read that slightly differently. I read that as: "even after putting the shoes on, the marathon still needs to be run". So yes, lifting reasoning burden away from eg. function interfaces (owning vs uniquely borrowing vs shared borrowing), lifetime problems (and so on), precisely enables everyone to put/spend more "effort" on the remaining difficulties.