4 ms·

Reading through the descriptions of the fast and sophisticated memory synchronization techniques in Linux that Rust cannot express in safe code, I have to wonde

Reading through the descriptions of the fast and sophisticated memory synchronization techniques in Linux that Rust cannot express in safe code, I have to wonder how many optimization opportunities would have gone undiscovered, forever, if the kernel had been written in Rust from the start. Language shapes how we think about the world. Ideas that are hard to describe in the language of the mind are hard to imagine in the first place. What potential avenues for improvement might we lose by shifting computing to safe but constricting languages like Rust?

kaba0 5y ago
Rust is not confining at all, you always have an escape hatch through unsafe, but even without that, programs that fail to compile would mostly all be faulty ones.
- quotemstr 5y ago
  > Rust is not confining at all, Yes, it is, and the linked blog posts talk about how. Did you read them? My point isn't that some ideas can't be expressed in Rust. It's true that with sufficient effort, Rust can express anything. My point is that some ideas are harder and more awkward to express in Rust compared to C, and that as a result, people might have been less likely to invent those difficult-to-imagine ideas if they'd been working in Rust and not C. I'm basically arguing for the "weak" variant of the Sapir-Whorf hypothesis as applied to programming languages. The weak form of Sapir-Whorf is obviously true with respect to human languages. To the responses below: Yes, it's true that Rust's higher level of abstraction allows for optimizations difficult to express in C. It's worth pointing out that C++ has similar expressiveness but doesn't constrain access to the machine in the same way. > Sure some things might be harder to express in Rust, but the tradeoff is well worth it. You're missing my point. For some types of code, the safety Rust provides might be "worth it". I'm just suggesting that there really are performance-enhancing techniques that would have gone uninvented in a Rust-only world. You seem to be agreeing with me and adding on top that we don't need that stinking performance anyway, so nothing I said presents a problem. Can you see how someone might disagree with that perspective?
  - Ygg2 5y ago
    > Yes, it is Ok, let's assume it is confining (something that I disagree with). So what? Seat belts are confining as well. Sure some things might be harder to express in Rust, but the tradeoff is well worth it. I'd rather take the confinement or Rust, rather than pervasive paranoia of whether I'm going to hit C UB anywhere.
    - ezekiel68 5y ago
      You do well to point this out. Can you also see that the original claim was therefore overblown? (not an attack -- we all do it sometimes)
  - kaba0 5y ago
    Yeah, some ideas are harder in Rust than in C, but I argue that most of those should not be followed in the first place, and are the way due to C’s own Sapir-Whorf, whereas it can’t abstract away jack shit. Eg. the insane overuse of linked lists are pretty much not useful on any modern computer, and it is used all over C codebases due to the language not being able to abstract something as simple as a vector. C strings are also abominations, and are non-efficient on top of that! All of these are possible in an elegant/comfortable to use way in “higher-level” languages, like Rust and C++.
  - paavohtl 5y ago
    The opposite also holds true. Because Rust supports much higher level abstractions than C, it can be much faster and easier to experiment with different designs than with C. Parallelism is the classic example, but I also really like Bryan Cantrill's blog post from 2018 [1], where he was able to use a BTreeMap as a drop-in replacement for a HashMap, and gain a lot of performance that way. [1] http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
  - d3nj4l 5y ago
    Regardless of anything else you've said; The weak form of Sapir-Whorf is obviously true with respect to human languages. No, it's not. Nothing is "obviously true", least of all a pretty grandiose theory, and I can't find any source that empirically backs up the idea that the weak version of the hypothesis is true at all.
unrealhoang 5y ago
Regarding performance, the opposite side of your question is as relevant, how many optimization opportunities would have been skipped because the C API is too hard to guarantee correct usage [1]? Rust has already surpassed C on the benchmark game, can that be used as data points? [1]: http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
- igouy 5y ago
  > Rust has already surpassed C on the benchmark game… Surpassed? Looks kind-of similar.
- Jensson 5y ago
  The rust they write for those benchmarks looks like this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/revcomp-rust-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Just as safe and fast as C++, but with more work done to micro optimize.
  - SubjectToChange 5y ago
    You should read the author's other post: http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-... They weren't trying to game benchmarks in their analysis.

kaba0 5y ago

Rust is not confining at all, you always have an escape hatch through unsafe, but even without that, programs that fail to compile would mostly all be faulty ones.

quotemstr 5y ago
> Rust is not confining at all, Yes, it is, and the linked blog posts talk about how. Did you read them? My point isn't that some ideas can't be expressed in Rust. It's true that with sufficient effort, Rust can express anything. My point is that some ideas are harder and more awkward to express in Rust compared to C, and that as a result, people might have been less likely to invent those difficult-to-imagine ideas if they'd been working in Rust and not C. I'm basically arguing for the "weak" variant of the Sapir-Whorf hypothesis as applied to programming languages. The weak form of Sapir-Whorf is obviously true with respect to human languages. To the responses below: Yes, it's true that Rust's higher level of abstraction allows for optimizations difficult to express in C. It's worth pointing out that C++ has similar expressiveness but doesn't constrain access to the machine in the same way. > Sure some things might be harder to express in Rust, but the tradeoff is well worth it. You're missing my point. For some types of code, the safety Rust provides might be "worth it". I'm just suggesting that there really are performance-enhancing techniques that would have gone uninvented in a Rust-only world. You seem to be agreeing with me and adding on top that we don't need that stinking performance anyway, so nothing I said presents a problem. Can you see how someone might disagree with that perspective?
- Ygg2 5y ago
  > Yes, it is Ok, let's assume it is confining (something that I disagree with). So what? Seat belts are confining as well. Sure some things might be harder to express in Rust, but the tradeoff is well worth it. I'd rather take the confinement or Rust, rather than pervasive paranoia of whether I'm going to hit C UB anywhere.
  - ezekiel68 5y ago
    You do well to point this out. Can you also see that the original claim was therefore overblown? (not an attack -- we all do it sometimes)
- kaba0 5y ago
  Yeah, some ideas are harder in Rust than in C, but I argue that most of those should not be followed in the first place, and are the way due to C’s own Sapir-Whorf, whereas it can’t abstract away jack shit. Eg. the insane overuse of linked lists are pretty much not useful on any modern computer, and it is used all over C codebases due to the language not being able to abstract something as simple as a vector. C strings are also abominations, and are non-efficient on top of that! All of these are possible in an elegant/comfortable to use way in “higher-level” languages, like Rust and C++.
- paavohtl 5y ago
  The opposite also holds true. Because Rust supports much higher level abstractions than C, it can be much faster and easier to experiment with different designs than with C. Parallelism is the classic example, but I also really like Bryan Cantrill's blog post from 2018 [1], where he was able to use a BTreeMap as a drop-in replacement for a HashMap, and gain a lot of performance that way. [1] http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
- d3nj4l 5y ago
  Regardless of anything else you've said; The weak form of Sapir-Whorf is obviously true with respect to human languages. No, it's not. Nothing is "obviously true", least of all a pretty grandiose theory, and I can't find any source that empirically backs up the idea that the weak version of the hypothesis is true at all.

unrealhoang 5y ago

Regarding performance, the opposite side of your question is as relevant, how many optimization opportunities would have been skipped because the C API is too hard to guarantee correct usage [1]? Rust has already surpassed C on the benchmark game, can that be used as data points? [1]: http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

igouy 5y ago
> Rust has already surpassed C on the benchmark game… Surpassed? Looks kind-of similar.
Jensson 5y ago
The rust they write for those benchmarks looks like this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/revcomp-rust-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Just as safe and fast as C++, but with more work done to micro optimize.
- SubjectToChange 5y ago
  You should read the author's other post: http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-... They weren't trying to game benchmarks in their analysis.