4 ms·

Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? I know that the parent post used multi-threading

Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory? I know that the parent post used multi-threading as an argument in favor of Rust. But there are many ways to blow of your foot in single threaded C++. For example, consider this single-threaded code: std::vector<size_t> v; v.push_back(1); size_t *first = &v[0]; std::cout << *first << std::endl; // The STL vector implementation will probably // reallocate the backing array at least once. for (size_t i = 2; i < 1000; i++) v.push_back(i); std::cout << *first << std::endl; You wouldn't be able to introduce the same error in Rust. Once you borrow the an element of a Vec immutably, you cannot create mutable borrows during the lifetime of any immutable borrows. So the compiler would reject pushing new elements. However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me The thing is that most of the errors that the borrow checker will point out are potential programming errors in C or C++ as well. However, current C/C++ compilers will put most of the responsibility completely on you (plus tools like Valgrind). So, to me C++ has at least the same cognitive load if you want to program responsibly.

rtpg 8y ago
I agree with the general principle, but programming in Rust is not "program in C++, then fix errors". You really need to lay your code in away that will satisfy the checkers. That or jump into unsafe mode. A good example of the challenge is that there's unsafe inner code in rusts own container code. If you try to build your own custom containers (or things like arenas) you'll likely work with unsafe code... Or rely on rusts container code (not a bad thing of course). My feeling is that "C to Rust" is close to "Java to Haskell" more than anything else. The extra layers are important enough that they need a new thought process. (I say this as a proponent of rust)
- xfer 8y ago
  Same thing is also true in C++, the stdlib also uses "unsafe" pointers inside, but you can use unique, shared etc. > You really need to lay your code in away that will satisfy the checkers. There are some patterns that are common but problematic but are being addressed by non-lexical lifetimes. Other than that it's almost "program in C++, then fix errors".
- danieldk 8y ago
  You really need to lay your code in away that will satisfy the checkers. But that becomes a second nature after a while. I think all the edge cases that still exist make it more problematic. E.g. I was writing some SIMD code yesterday with a loop somewhat like this (simplified): let mut v = vec![1.0, 2.0, 3.0, 4.0, 5.0, 6.0]; let mut s: &mut [f32] = &mut v; while s.len() >= 2 { println!("{:?}", s); s = &mut s[2..]; } Playground: https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373eca7fa https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373e... It makes you scratch your head for a bit. A good example of the challenge is that there's unsafe inner code in rusts own container code. I am pretty proud that one of my first small Rust projects was a randomized ternary trie. Apparently, it does not use unsafe anywhere. https://github.com/danieldk/rtrie/blob/master/src/ternary.rs https://github.com/danieldk/rtrie/blob/master/src/ternary.rs Not that I am proud of the code ;). But in all seriousness, unsafe in container code is somewhat expected, because at some point you need to wrap raw memory (as e.g. in Vec). I think quite a bit of, but probably not all, unsafe use in containers such as Vec comes from that.

rtpg 8y ago

I agree with the general principle, but programming in Rust is not "program in C++, then fix errors". You really need to lay your code in away that will satisfy the checkers. That or jump into unsafe mode. A good example of the challenge is that there's unsafe inner code in rusts own container code. If you try to build your own custom containers (or things like arenas) you'll likely work with unsafe code... Or rely on rusts container code (not a bad thing of course). My feeling is that "C to Rust" is close to "Java to Haskell" more than anything else. The extra layers are important enough that they need a new thought process. (I say this as a proponent of rust)

xfer 8y ago
Same thing is also true in C++, the stdlib also uses "unsafe" pointers inside, but you can use unique, shared etc. > You really need to lay your code in away that will satisfy the checkers. There are some patterns that are common but problematic but are being addressed by non-lexical lifetimes. Other than that it's almost "program in C++, then fix errors".
danieldk 8y ago
You really need to lay your code in away that will satisfy the checkers. But that becomes a second nature after a while. I think all the edge cases that still exist make it more problematic. E.g. I was writing some SIMD code yesterday with a loop somewhat like this (simplified): let mut v = vec![1.0, 2.0, 3.0, 4.0, 5.0, 6.0]; let mut s: &mut [f32] = &mut v; while s.len() >= 2 { println!("{:?}", s); s = &mut s[2..]; } Playground: https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373eca7fa https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373e... It makes you scratch your head for a bit. A good example of the challenge is that there's unsafe inner code in rusts own container code. I am pretty proud that one of my first small Rust projects was a randomized ternary trie. Apparently, it does not use unsafe anywhere. https://github.com/danieldk/rtrie/blob/master/src/ternary.rs https://github.com/danieldk/rtrie/blob/master/src/ternary.rs Not that I am proud of the code ;). But in all seriousness, unsafe in container code is somewhat expected, because at some point you need to wrap raw memory (as e.g. in Vec). I think quite a bit of, but probably not all, unsafe use in containers such as Vec comes from that.