8 ms·

The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. P

The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. Possibly also that a significant portion of the suggested gain may be achievable via other means. i.e. bounds checking and some simple (RAII-like) allocation/freeing simplifications may be possible without rust, and that those are (from the various papers arguing for Rust / memory safety elsewhere) the larger proportion of the safety bugs which Rust catches. Possibly just making clang the required compiler, and adopting these extension may give an easier bang-for-buck: https://clang.llvm.org/docs/BoundsSafety.html https://clang.llvm.org/docs/BoundsSafety.html Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such.

mustache_kimono 2y ago
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. Read the above email. Greg KH is pretty certain it is worth the gain. > Possibly also that a significant portion of the suggested gain may be achievable via other means. I think this is a valid POV, if someone shows up and does the work. And I don't mean 3 years ago. I mean -- now is as good a time as any to fix C code, right? If you have some big fixes, it's not like the market won't reward you for them. It's very, very tempting to think there is some other putatively simpler solution on the horizon, but we haven't seen one. > Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such. No accounting for taste, but I don't think C is beautiful! Rust feels very understandable and explicit to my eye, whereas C feels very implicit and sometimes inscrutable.
- whstl 2y ago
  > Read the above email. Greg KH is pretty certain it is worth the gain. I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here.
  - mustache_kimono 2y ago
    > I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here. Glad for your keen insights.
0x457 2y ago
I think it's because C devs often think that they never make a mistake, so they see rust bringing on value. I had an argument about rust with a freebsd developer that had the same "I never make a mistake" attitude. I've made a PR to his project that fixes bugs that weren't possible in rust to being with. Not out of petty, but because his library was crashing my application. In fact, he tried to blame my rust wrapper for it when I raised an issue.
- EasyMark 2y ago
  I have definitely done such things out of pettiness. Sometimes people just attract your attention as deserving of an attempt to humble them. I hope people will humble me as well when my vociferousness outstrips my talent. It's good to be sent directly back to home every now and then.
  - dc443 2y ago
    What i don't get is why people gravitate toward trying to show off how many symbols they're able to manipulate in their brain without screwing something up. It's a computer. It does what it was instructed to do, all 50 million or so of them. To think you as a puny human have complete and utter mastery over it is pure folly every single time. As time goes on I become more convinced that the way to make progress in computing and software is not with better languages, sure, those are very much appreciated, since language has a strong impact on how you even think about problems, but it's more about tooling and how we can add abstractions to the software to leverage the computer we already got to alleviate the eye gouging complexity of trying to manage it all by trying to predict how it will behave with our pitiful neuron sacs.
    - 0x457 2y ago
      Don't forget about naming variables like it's a punchcard and every character matters.
mimd 2y ago
If you look at the CVE lists, about 70-80% of all c memory bugs are related to OOB Read and Write. Additionally, like rust, fbounds-safety can remove redundant checks if it can determine the bounds. My question is how likely can it be adopted in the kernel (likely high). I will need to read their conversations more to see if it's the underlying fear, but formalization makes refactoring hard and code brittle (ie. having to start from scratch on a formal proof after substantially changing a subsystem). One of the key benefits of C/Kernel have been their malleability to new hardware and requirements.
- whytevuhuni 2y ago
  > My question is how likely can it be adopted in the kernel (likely high). My guess is, it cannot. The way -fbounds-safety works, as far as I understand, is that it aborts the program in case of an out-of-bounds read or write. This is similar to a Rust panic. Aborting or panicking the kernel is absolutely not a better alternative to simply allowing the read/write to happen, even if it results in a memory vulnerability. Turning people's computer off whenever a driver stumbles on a bug is not acceptable. Most people cannot debug a kernel panic, and won't even have a way to see it. Rust can side-step this with its `.get()` (which returns an Option, which can be converted to an error value), and with iterators, which often bypass the need for indexing in the first place. Unfortunately, Rust can still panic in case of a normal indexing operation that does OOB access; my guess is that the index operation will quickly be fixed to be completely disallowed in the kernel as soon as the first such bug hits production servers and desktop PCs. Alternatively, it might be changed to always do buf[i % buf.size()], so that it gives the wrong answer, but stays within bounds (making it similar to other logic errors, as opposed to a memory corruption error).
  - mimd 2y ago
    Yes, panicking in kernels is bad. I've followed the whole R4L fight about working around it. https://github.com/apple-oss-distributions/xnu/blob/main/doc/building/bound_checks.md https://github.com/apple-oss-distributions/xnu/blob/main/doc... https://github.com/apple-oss-distributions/xnu/blob/main/doc/building/bound_checks.md#where-bound-checks-soft-comes-in https://github.com/apple-oss-distributions/xnu/blob/main/doc... Upstream fbounds in xnu has options for controlling if it panics or is just a telemetry event. They are in a kernel situation and have the exact same considerations on trying to keep the kernel alive.
viraptor 2y ago
> Possibly also that a significant portion of the suggested gain may be achievable via other means. Things like that have been said many times, even before Rust came around. You can do static analysis, you can put in asserts, you can use this restricted C dialect, you can... But this never gets wider usage. Even if the tools are there, people are going to ignore them. https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) started 23 years ago... It took us decades to get to non executable stack and W^X and there are still occasional issues with that.
deleted 2y ago
[deleted]
throwawaymaths 2y ago
the problem is that Rust sucks the air out of the programming ecosystem because its proponents throw down the safety hammer, and research on other safe alternatives is slow. we do have an alternative low level memory safe language (Ada) but for whatever reason that's a nonstarter... there's no compelling reason that rust has to be the only way to achieve memory safety (much less in the OS domain where for example you don't have malloc/free so rust's default heap allocation can't be trivially used). it might do to wait until some other memory safe alternative appears.
- dralley 2y ago
  Linus doesn't like ADA much, and the talent pool is FAR smaller and also FAR older on average. The compelling reason to use Rust over other languages is precisely that it hit escape velocity where others failed to do so, and it did that partially by being accessible to less senior programmers. And I don't understand how you can go from opining that Rust shouldn't be the only other option, to opining that they should have waited before supporting Rust. That doesn't make sense unless you just have a particular animus towards Rust.
  - throwawaymaths 2y ago
    yeah i do! rust does a lot of things right but protocols and proc macros are awful, as is raii.
    - kelnos 2y ago
      I mean, that's just your opinion. I agree that proc macros are awful. I'm not sure what "protocols" are in reference to Rust. And as for RAII, I get that it can be contentious at times, but I generally appreciate its existence. But our opinions on this are irrelevant, as it turns out, unless you're actually Linus Torvalds hiding behind that throwaway account.
      - evertedsphere 2y ago
        traits probably
petesergeant 2y ago
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. You're correct that there is a honest-to-god split of opinion by smart people who can't find a consensus opinion. So it's time for Linus to step up and mandate and say "discussion done, we are doing x". No serious organization of humans can survive without a way to break a deadlock, and it seems long past the time this discussion should have wrapped up with Linus making a decree (or whatever alternative voting mechanism they want to use).
kelnos 2y ago
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. [..] Possibly also that a significant portion of the suggested gain may be achievable via other means. Sure, but opinions are always going to differ on stuff like this. Decision-making for the Linux kernel does not require unanimous consent, and that's a good thing. Certainly this Rust push hasn't been handled perfectly, by any means, but I think they at least have a decent plan in place to make sure maintainers who don't want to touch Rust don't have to, and those who do can have a say in how the Rust side of their subsystems look. I agree with the people who don't believe you can get Rust-like guarantees using C or C++. C is just never going to give you that, ever, by design. C++ maybe will, someday, years or decades from now, but you'll always have the problem of defining your "safe subset" and ensuring that everyone sticks to it. Rust is of course not a silver bullet, but it has some properties that mean you just can't write certain kind of bugs in safe Rust and get the compiler to accept it. That's incredibly useful, and you can't get that from C or C++ today, and possibly not ever. Yes, there are tools that exist for C to do formal verification, but for whatever reason, no one wants to use them. A tool that people don't want to use might as well not exist. But ultimately my or your opinion on what C and C++ can or can't deliver is irrelevant. If people like Torvalds and Kroah-Hartman think Rust is a better bet than C/C++-based options, then that's what matters.
qalmakka 2y ago
> the readability and aesthetics of Rust code I've been writing C/C++ code for the last 16 years and I think a lot of mental gymnastics is required in order to call C "more readable" than Rust. C syntax is only "logical" and "readable" because people have been writing it for the last 60 years, most of it is literally random hacks made due to constraints ({ instead of [ because they thought that array would be more common than blocks, types in front of variables because C is just B with types, wonky pointer syntax, ...). It's like claiming that English spelling is "rational" and "obvious" only because it's the only language you know IMHO. Rust sure has more features but it also way more regular and less quirky. And it has real macros, instead of insane text replacement, every C project over 10k lines I've worked on has ALWAYS had some insane macro magic. The Linux kernel itself is full of function-like macros that do any sort of magic due to C not having any way to run code at compile-time at all.

mustache_kimono 2y ago

> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. Read the above email. Greg KH is pretty certain it is worth the gain. > Possibly also that a significant portion of the suggested gain may be achievable via other means. I think this is a valid POV, if someone shows up and does the work. And I don't mean 3 years ago. I mean -- now is as good a time as any to fix C code, right? If you have some big fixes, it's not like the market won't reward you for them. It's very, very tempting to think there is some other putatively simpler solution on the horizon, but we haven't seen one. > Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such. No accounting for taste, but I don't think C is beautiful! Rust feels very understandable and explicit to my eye, whereas C feels very implicit and sometimes inscrutable.

whstl 2y ago
> Read the above email. Greg KH is pretty certain it is worth the gain. I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here.
- mustache_kimono 2y ago
  > I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here. Glad for your keen insights.

0x457 2y ago

I think it's because C devs often think that they never make a mistake, so they see rust bringing on value. I had an argument about rust with a freebsd developer that had the same "I never make a mistake" attitude. I've made a PR to his project that fixes bugs that weren't possible in rust to being with. Not out of petty, but because his library was crashing my application. In fact, he tried to blame my rust wrapper for it when I raised an issue.

EasyMark 2y ago
I have definitely done such things out of pettiness. Sometimes people just attract your attention as deserving of an attempt to humble them. I hope people will humble me as well when my vociferousness outstrips my talent. It's good to be sent directly back to home every now and then.
- dc443 2y ago
  What i don't get is why people gravitate toward trying to show off how many symbols they're able to manipulate in their brain without screwing something up. It's a computer. It does what it was instructed to do, all 50 million or so of them. To think you as a puny human have complete and utter mastery over it is pure folly every single time. As time goes on I become more convinced that the way to make progress in computing and software is not with better languages, sure, those are very much appreciated, since language has a strong impact on how you even think about problems, but it's more about tooling and how we can add abstractions to the software to leverage the computer we already got to alleviate the eye gouging complexity of trying to manage it all by trying to predict how it will behave with our pitiful neuron sacs.
  - 0x457 2y ago
    Don't forget about naming variables like it's a punchcard and every character matters.

mimd 2y ago

If you look at the CVE lists, about 70-80% of all c memory bugs are related to OOB Read and Write. Additionally, like rust, fbounds-safety can remove redundant checks if it can determine the bounds. My question is how likely can it be adopted in the kernel (likely high). I will need to read their conversations more to see if it's the underlying fear, but formalization makes refactoring hard and code brittle (ie. having to start from scratch on a formal proof after substantially changing a subsystem). One of the key benefits of C/Kernel have been their malleability to new hardware and requirements.

whytevuhuni 2y ago
> My question is how likely can it be adopted in the kernel (likely high). My guess is, it cannot. The way -fbounds-safety works, as far as I understand, is that it aborts the program in case of an out-of-bounds read or write. This is similar to a Rust panic. Aborting or panicking the kernel is absolutely not a better alternative to simply allowing the read/write to happen, even if it results in a memory vulnerability. Turning people's computer off whenever a driver stumbles on a bug is not acceptable. Most people cannot debug a kernel panic, and won't even have a way to see it. Rust can side-step this with its `.get()` (which returns an Option, which can be converted to an error value), and with iterators, which often bypass the need for indexing in the first place. Unfortunately, Rust can still panic in case of a normal indexing operation that does OOB access; my guess is that the index operation will quickly be fixed to be completely disallowed in the kernel as soon as the first such bug hits production servers and desktop PCs. Alternatively, it might be changed to always do buf[i % buf.size()], so that it gives the wrong answer, but stays within bounds (making it similar to other logic errors, as opposed to a memory corruption error).
- mimd 2y ago
  Yes, panicking in kernels is bad. I've followed the whole R4L fight about working around it. https://github.com/apple-oss-distributions/xnu/blob/main/doc/building/bound_checks.md https://github.com/apple-oss-distributions/xnu/blob/main/doc... https://github.com/apple-oss-distributions/xnu/blob/main/doc/building/bound_checks.md#where-bound-checks-soft-comes-in https://github.com/apple-oss-distributions/xnu/blob/main/doc... Upstream fbounds in xnu has options for controlling if it panics or is just a telemetry event. They are in a kernel situation and have the exact same considerations on trying to keep the kernel alive.

viraptor 2y ago

> Possibly also that a significant portion of the suggested gain may be achievable via other means. Things like that have been said many times, even before Rust came around. You can do static analysis, you can put in asserts, you can use this restricted C dialect, you can... But this never gets wider usage. Even if the tools are there, people are going to ignore them. https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) started 23 years ago... It took us decades to get to non executable stack and W^X and there are still occasional issues with that.

deleted 2y ago

[deleted]

throwawaymaths 2y ago

the problem is that Rust sucks the air out of the programming ecosystem because its proponents throw down the safety hammer, and research on other safe alternatives is slow. we do have an alternative low level memory safe language (Ada) but for whatever reason that's a nonstarter... there's no compelling reason that rust has to be the only way to achieve memory safety (much less in the OS domain where for example you don't have malloc/free so rust's default heap allocation can't be trivially used). it might do to wait until some other memory safe alternative appears.

dralley 2y ago
Linus doesn't like ADA much, and the talent pool is FAR smaller and also FAR older on average. The compelling reason to use Rust over other languages is precisely that it hit escape velocity where others failed to do so, and it did that partially by being accessible to less senior programmers. And I don't understand how you can go from opining that Rust shouldn't be the only other option, to opining that they should have waited before supporting Rust. That doesn't make sense unless you just have a particular animus towards Rust.
- throwawaymaths 2y ago
  yeah i do! rust does a lot of things right but protocols and proc macros are awful, as is raii.
  - kelnos 2y ago
    I mean, that's just your opinion. I agree that proc macros are awful. I'm not sure what "protocols" are in reference to Rust. And as for RAII, I get that it can be contentious at times, but I generally appreciate its existence. But our opinions on this are irrelevant, as it turns out, unless you're actually Linus Torvalds hiding behind that throwaway account.
    - evertedsphere 2y ago
      traits probably

petesergeant 2y ago

> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. You're correct that there is a honest-to-god split of opinion by smart people who can't find a consensus opinion. So it's time for Linus to step up and mandate and say "discussion done, we are doing x". No serious organization of humans can survive without a way to break a deadlock, and it seems long past the time this discussion should have wrapped up with Linus making a decree (or whatever alternative voting mechanism they want to use).

kelnos 2y ago

> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. [..] Possibly also that a significant portion of the suggested gain may be achievable via other means. Sure, but opinions are always going to differ on stuff like this. Decision-making for the Linux kernel does not require unanimous consent, and that's a good thing. Certainly this Rust push hasn't been handled perfectly, by any means, but I think they at least have a decent plan in place to make sure maintainers who don't want to touch Rust don't have to, and those who do can have a say in how the Rust side of their subsystems look. I agree with the people who don't believe you can get Rust-like guarantees using C or C++. C is just never going to give you that, ever, by design. C++ maybe will, someday, years or decades from now, but you'll always have the problem of defining your "safe subset" and ensuring that everyone sticks to it. Rust is of course not a silver bullet, but it has some properties that mean you just can't write certain kind of bugs in safe Rust and get the compiler to accept it. That's incredibly useful, and you can't get that from C or C++ today, and possibly not ever. Yes, there are tools that exist for C to do formal verification, but for whatever reason, no one wants to use them. A tool that people don't want to use might as well not exist. But ultimately my or your opinion on what C and C++ can or can't deliver is irrelevant. If people like Torvalds and Kroah-Hartman think Rust is a better bet than C/C++-based options, then that's what matters.

qalmakka 2y ago

> the readability and aesthetics of Rust code I've been writing C/C++ code for the last 16 years and I think a lot of mental gymnastics is required in order to call C "more readable" than Rust. C syntax is only "logical" and "readable" because people have been writing it for the last 60 years, most of it is literally random hacks made due to constraints ({ instead of [ because they thought that array would be more common than blocks, types in front of variables because C is just B with types, wonky pointer syntax, ...). It's like claiming that English spelling is "rational" and "obvious" only because it's the only language you know IMHO. Rust sure has more features but it also way more regular and less quirky. And it has real macros, instead of insane text replacement, every C project over 10k lines I've worked on has ALWAYS had some insane macro magic. The Linux kernel itself is full of function-like macros that do any sort of magic due to C not having any way to run code at compile-time at all.