6 ms·

Writing data structures is trivial in C/C++.

pie_flavor 4y ago
As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.
- DonaldPShimoda 4y ago
  It's blowing my mind how many commenters here don't understand this. Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.
  - indymike 4y ago
    > we keep finding serious bugs in code that is decades-old I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)
    - hn92726819 4y ago
      Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C. https://www.chromium.org/Home/chromium-security/memory-safety/piechart.png https://www.chromium.org/Home/chromium-security/memory-safet...
      - lll-o-lll 4y ago
        It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers. I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.
        hn92726819 4y ago
        > I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language. I could see that. Haven't used zig but it does look very nice. > in many places where unsafe ends up required Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.
      - indymike 4y ago
        > I don't understand why this argument keeps coming up. Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.
      - kprotty 4y ago
        > zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000... [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31162 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116... [3] https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam/RUSTSEC-2018-0009.md https://github.com/rustsec/advisory-db/blob/main/crates/cros... [4] https://github.com/rustsec/advisory-db/blob/main/crates/tokio/RUSTSEC-2021-0124.md https://github.com/rustsec/advisory-db/blob/main/crates/toki... [5] https://github.com/rustsec/advisory-db/tree/main/crates/ https://github.com/rustsec/advisory-db/tree/main/crates/ [6] https://github.com/Qwaz/rust-cve https://github.com/Qwaz/rust-cve
  - kaba0 4y ago
    While I do like Rust, let’s not forget that it indeed “forbids” to a degree many code/lifetime structures that are extremely common in basically every other language. I believe the tradeoff for this in Rust’s niche is absolutely acceptable, but it is still a tradeoff and might not be the correct choice in certain cases.
  - loeg 4y ago
    It's in part hard because the borrow checker isn't omniscient and accepts only a subset of safe programs. There are also some concepts it's difficult to explain to the borrow checker. Both of these are things that make writing programs harder in Rust that do not add any safety value, and it's ok to acknowledge that.
- haberman 4y ago
  That would be true if Rust was a perfect language, but it isn't (no language is). Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html
- Tarq0n 4y ago
  Not strictly true. Rust makes things hard by making you design within the limitations of the borrow checker, and some of those are accidental, not a necessary edge case.
bigbillheck 4y ago
Writing correct ones is not.
- deleted 4y ago
  [deleted]

As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.

DonaldPShimoda 4y ago
It's blowing my mind how many commenters here don't understand this. Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.
- indymike 4y ago
  > we keep finding serious bugs in code that is decades-old I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)
  - hn92726819 4y ago
    Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C. https://www.chromium.org/Home/chromium-security/memory-safety/piechart.png https://www.chromium.org/Home/chromium-security/memory-safet...
    - lll-o-lll 4y ago
      It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers. I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.
      - hn92726819 4y ago
        > I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language. I could see that. Haven't used zig but it does look very nice. > in many places where unsafe ends up required Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.
    - indymike 4y ago
      > I don't understand why this argument keeps coming up. Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.
    - kprotty 4y ago
      > zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000... [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31162 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116... [3] https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam/RUSTSEC-2018-0009.md https://github.com/rustsec/advisory-db/blob/main/crates/cros... [4] https://github.com/rustsec/advisory-db/blob/main/crates/tokio/RUSTSEC-2021-0124.md https://github.com/rustsec/advisory-db/blob/main/crates/toki... [5] https://github.com/rustsec/advisory-db/tree/main/crates/ https://github.com/rustsec/advisory-db/tree/main/crates/ [6] https://github.com/Qwaz/rust-cve https://github.com/Qwaz/rust-cve
- kaba0 4y ago
  While I do like Rust, let’s not forget that it indeed “forbids” to a degree many code/lifetime structures that are extremely common in basically every other language. I believe the tradeoff for this in Rust’s niche is absolutely acceptable, but it is still a tradeoff and might not be the correct choice in certain cases.
- loeg 4y ago
  It's in part hard because the borrow checker isn't omniscient and accepts only a subset of safe programs. There are also some concepts it's difficult to explain to the borrow checker. Both of these are things that make writing programs harder in Rust that do not add any safety value, and it's ok to acknowledge that.
haberman 4y ago
That would be true if Rust was a perfect language, but it isn't (no language is). Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html
Tarq0n 4y ago
Not strictly true. Rust makes things hard by making you design within the limitations of the borrow checker, and some of those are accidental, not a necessary edge case.

bigbillheck 4y ago

Writing correct ones is not.

deleted 4y ago
[deleted]