7 ms·

> IMO Rust has yet to prove it isn’t another overly complicated C++ waiting to make projects almost incomprehensible to understand Rust is relatively easy to r

> IMO Rust has yet to prove it isn’t another overly complicated C++ waiting to make projects almost incomprehensible to understand Rust is relatively easy to read I think. The borrow checker is what gets all the hate, but that is an issue for writing, not reading. If anything, things like pattern matching make otherwise long if chains easier to read IMO > we have yet to see tangible benefits of using Rust Rust eradicates whole classes of errors in safe code, and unsafe code is more safe than the equivalent C or C++. The only theoretical way to not have a tangible reduction in errors would be to believe that a C programmer is good enough to never commit the error classes Rust eradicates, and believe Rust usage would increase the number of logic errors. This seems incredibly unlikely to me.

nyanpasu64 4y ago
Unsafe Rust that exposes & or &mut to safe code is more unsafe than the equivalent C or C++.
- hgomersall 4y ago
  Perhaps you can clarify - if you're saying unsafe rust that performs undefined behaviour is unsafe regardless of the safe bits, then you'll have no disagreement. If on the other hand you're suggesting that it's possible to have well defined unsafe rust that exposes a lack of safety across the unsafe boundary, then you're going to have to explain a bit more...
  - nyanpasu64 4y ago
    In Rust, casting a *mut to a &mut (the standard method of allowing safe code to mutate an object) is unsafe if other &, &mut, or Pin<&mut> exists, regardless of whether or not you commit a use-after-free. In C++, the equivalent code interchangeably using * and & is safe until you actually commit a use-after-free. This makes it harder to write correct Rust code mixing safe and unsafe code.
    - hgomersall 4y ago
      But the casting is specified as unsafe, so if you do it (in `unsafe` code) and don't check that its safe, then you're breaking the safety contract. The whole point of `unsafe` is to define a clear boundary across which invariants must be upheld. In this case, it's those given here: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_mut https://doc.rust-lang.org/std/primitive.pointer.html#method.... What's the use case for wanting to convert an invalid pointer to a `&mut` and then not use it? If I'm missing something, perhaps you could show me some code that highlights the problem (on, say, rust playground).
      - nyanpasu64 4y ago
        It's not just dereferencing invalid */& that's illegal in Rust, but constructing and dereferencing valid &/&mut in ways that don't respect tree-shaped mutability. I've put together a playground at https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3b5066c3f091b34b981d7d0ca8748c4d https://play.rust-lang.org/?version=stable&mode=debug&editio.... "Object graph" architectures are common in C++ and sometimes necessary in Rust when building GUI applications or emulators. Rust's pointer aliasing rules invalidate otherwise-correct code, placing roadblocks in the way of writing correct code. And there's so much creation of &mut (which invalidates aliasing pointers for the duration of the &mut, and invalidates sibling &mut and all pointers constructed from them), that's so implicit I don't know what's legal and what's not by auditing code. (Box<T> used to also invalidate aliasing pointers, but this may be changed. The current plan for enabling self-reference is Pin<&mut T>, but the exact semantics for how and when putting a &mut T in a wrapper struct makes it not invalidate self-reference and incoming pointers, is still not specified.) I've heard statements that addr_of_mut! is an interim API, and the situation may be improved with &raw and unsafe-deref syntax (https://faultlore.com/blah/fix-rust-pointers/ https://faultlore.com/blah/fix-rust-pointers/). But I expect a production systems language to be an improvement upon C/C++'s usability in their strongest domains out of the box (much like how Send/Sync as marker types not creating UB beyond C++ makes threading more tractable, and enums are superior to std::variant). Instead today's Rust pointer rules redefines swathes of C and C++'s use cases and design patterns as undefined behavior, and the alternative approaches are ugly to express in safe code (Cell/RefCell), and easy to get wrong and tricky and ugly to get right in unsafe code (see my playground), with the promise that they were trying to make programming easier and are trying to create a suitable replacement someday down the line (7 years and counting after Rust 1.0). It reminds me of C++'s long-running object lifetime saga (https://en.cppreference.com/w/cpp/language/lifetime https://en.cppreference.com/w/cpp/language/lifetime, https://www.reddit.com/r/cpp_questions/comments/dfglt2 https://www.reddit.com/r/cpp_questions/comments/dfglt2), but I've never had to deal with this mess directly, unlike Rust object graphs.
maccard 4y ago
> Rust is relatively easy to read I think. I write C++, Kotlin and Go code day to day, and I respectfully disagree. the syntax is incredibly terse. Most rust code I've encountered sprinkles macros with functions, which have slightly different semantics (note this is not an indictment of C or C++'s macros, far from it), and the combination of macros, pattern matching and unwrap lead to code like [0], which frankly I find incredibly difficult to work with. > Rust eradicates whole classes of errors in safe code, and unsafe code is more safe than the equivalent C or C++. Completely agree here, and nopt only does it do that it does so _without sacrificing performance_ in many cases. [0] https://github.com/mozilla/sccache/blob/main/src/compiler/gcc.rs#L275 https://github.com/mozilla/sccache/blob/main/src/compiler/gc...
- nu11ptr 4y ago
  I suspect the style and library code used matters greatly. Said differently, the constructs that Rust has make it _possible_ IMO to write code that is easier to read than equivalent C. Obviously even this depends, as the simplest use case will look very simple in C, but the most complex use case it is possible to write cleaner looking code in Rust due to he inclusion of higher level constructs that C simply does not have, so it typically resorts to hiding this via macros.
  - maccard 4y ago
    I've only interacted with a small amount of rust code over the last 3-4 years, but it's all been a similar style to the above. I'd love to be proven wrong with any examples of well written understandable rust code though!
- johnisgood 4y ago
  What even is "if let ..." in Rust? What is the purpose of it? need_explicit_dep_target = true; if let DepArgumentRequirePath::NotNeeded = need_explicit_dep_argument_path { need_explicit_dep_argument_path = DepArgumentRequirePath::Missing; } I am currently trying to translate "simple" Rust code to C but I am having difficulties. https://github.com/RustCrypto/formats/blob/master/base32ct/src/alphabet.rs#L43 https://github.com/RustCrypto/formats/blob/master/base32ct/s... Where is `threshold` and `offset` coming from? How come running `cargo test` in directory `base32ct` actually tests nothing (I get 0 everywhere) despite there being some test code? Messed up `Cargo.toml` file? sighs Lots of mysteries in Rust, at least for me.

nyanpasu64 4y ago

Unsafe Rust that exposes & or &mut to safe code is more unsafe than the equivalent C or C++.

hgomersall 4y ago
Perhaps you can clarify - if you're saying unsafe rust that performs undefined behaviour is unsafe regardless of the safe bits, then you'll have no disagreement. If on the other hand you're suggesting that it's possible to have well defined unsafe rust that exposes a lack of safety across the unsafe boundary, then you're going to have to explain a bit more...
- nyanpasu64 4y ago
  In Rust, casting a *mut to a &mut (the standard method of allowing safe code to mutate an object) is unsafe if other &, &mut, or Pin<&mut> exists, regardless of whether or not you commit a use-after-free. In C++, the equivalent code interchangeably using * and & is safe until you actually commit a use-after-free. This makes it harder to write correct Rust code mixing safe and unsafe code.
  - hgomersall 4y ago
    But the casting is specified as unsafe, so if you do it (in `unsafe` code) and don't check that its safe, then you're breaking the safety contract. The whole point of `unsafe` is to define a clear boundary across which invariants must be upheld. In this case, it's those given here: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_mut https://doc.rust-lang.org/std/primitive.pointer.html#method.... What's the use case for wanting to convert an invalid pointer to a `&mut` and then not use it? If I'm missing something, perhaps you could show me some code that highlights the problem (on, say, rust playground).
    - nyanpasu64 4y ago
      It's not just dereferencing invalid */& that's illegal in Rust, but constructing and dereferencing valid &/&mut in ways that don't respect tree-shaped mutability. I've put together a playground at https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3b5066c3f091b34b981d7d0ca8748c4d https://play.rust-lang.org/?version=stable&mode=debug&editio.... "Object graph" architectures are common in C++ and sometimes necessary in Rust when building GUI applications or emulators. Rust's pointer aliasing rules invalidate otherwise-correct code, placing roadblocks in the way of writing correct code. And there's so much creation of &mut (which invalidates aliasing pointers for the duration of the &mut, and invalidates sibling &mut and all pointers constructed from them), that's so implicit I don't know what's legal and what's not by auditing code. (Box<T> used to also invalidate aliasing pointers, but this may be changed. The current plan for enabling self-reference is Pin<&mut T>, but the exact semantics for how and when putting a &mut T in a wrapper struct makes it not invalidate self-reference and incoming pointers, is still not specified.) I've heard statements that addr_of_mut! is an interim API, and the situation may be improved with &raw and unsafe-deref syntax (https://faultlore.com/blah/fix-rust-pointers/ https://faultlore.com/blah/fix-rust-pointers/). But I expect a production systems language to be an improvement upon C/C++'s usability in their strongest domains out of the box (much like how Send/Sync as marker types not creating UB beyond C++ makes threading more tractable, and enums are superior to std::variant). Instead today's Rust pointer rules redefines swathes of C and C++'s use cases and design patterns as undefined behavior, and the alternative approaches are ugly to express in safe code (Cell/RefCell), and easy to get wrong and tricky and ugly to get right in unsafe code (see my playground), with the promise that they were trying to make programming easier and are trying to create a suitable replacement someday down the line (7 years and counting after Rust 1.0). It reminds me of C++'s long-running object lifetime saga (https://en.cppreference.com/w/cpp/language/lifetime https://en.cppreference.com/w/cpp/language/lifetime, https://www.reddit.com/r/cpp_questions/comments/dfglt2 https://www.reddit.com/r/cpp_questions/comments/dfglt2), but I've never had to deal with this mess directly, unlike Rust object graphs.

maccard 4y ago

> Rust is relatively easy to read I think. I write C++, Kotlin and Go code day to day, and I respectfully disagree. the syntax is incredibly terse. Most rust code I've encountered sprinkles macros with functions, which have slightly different semantics (note this is not an indictment of C or C++'s macros, far from it), and the combination of macros, pattern matching and unwrap lead to code like [0], which frankly I find incredibly difficult to work with. > Rust eradicates whole classes of errors in safe code, and unsafe code is more safe than the equivalent C or C++. Completely agree here, and nopt only does it do that it does so _without sacrificing performance_ in many cases. [0] https://github.com/mozilla/sccache/blob/main/src/compiler/gcc.rs#L275 https://github.com/mozilla/sccache/blob/main/src/compiler/gc...

nu11ptr 4y ago
I suspect the style and library code used matters greatly. Said differently, the constructs that Rust has make it _possible_ IMO to write code that is easier to read than equivalent C. Obviously even this depends, as the simplest use case will look very simple in C, but the most complex use case it is possible to write cleaner looking code in Rust due to he inclusion of higher level constructs that C simply does not have, so it typically resorts to hiding this via macros.
- maccard 4y ago
  I've only interacted with a small amount of rust code over the last 3-4 years, but it's all been a similar style to the above. I'd love to be proven wrong with any examples of well written understandable rust code though!
johnisgood 4y ago
What even is "if let ..." in Rust? What is the purpose of it? need_explicit_dep_target = true; if let DepArgumentRequirePath::NotNeeded = need_explicit_dep_argument_path { need_explicit_dep_argument_path = DepArgumentRequirePath::Missing; } I am currently trying to translate "simple" Rust code to C but I am having difficulties. https://github.com/RustCrypto/formats/blob/master/base32ct/src/alphabet.rs#L43 https://github.com/RustCrypto/formats/blob/master/base32ct/s... Where is `threshold` and `offset` coming from? How come running `cargo test` in directory `base32ct` actually tests nothing (I get 0 everywhere) despite there being some test code? Messed up `Cargo.toml` file? sighs Lots of mysteries in Rust, at least for me.