4 ms·

If I recall correctly, Torvalds already addressed the hype around this ( totally not new ) idea by pointing out that memory errors really make up only tiny part

by ajxs 7y ago

If I recall correctly, Torvalds already addressed the hype around this ( totally not new ) idea by pointing out that memory errors really make up only tiny part of the intricacies of building a kernel. This idea predates Rust, and for better or worse will probably outlive it.

WilliamEdward 7y ago
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.

by ajxs 7y ago

WilliamEdward 7y ago

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.