4 ms·

> Every large C++ app I've ever seen has fallen to some memory error or another. I think "I don't care about the errors" is a legitimate reason to use C++, but

> Every large C++ app I've ever seen has fallen to some memory error or another. I think "I don't care about the errors" is a legitimate reason to use C++, but "I don't have to care" isn't. I very much agree. Although few people would say "I don't care about the errors", out loud, even if that sentiment is valid in certain contexts. In that light, I have a question for you: What other concurrency features does Rust offer over C++ outside of data race freedom guarantees?

dikaiosune 11y ago
Does C++ have the ability to safely share stack data without copying? I don't think so, but I'm not an expert. Rust has a few libraries that enable stack-scoped threads that are safe by virtue of ensuring that all threads created in the scope terminate before the data they reference is dropped (EDIT: and by preventing mutation of shared state without guarantees about atomic operations). For example, I'm working on a project that uses crossbeam: https://aturon.github.io/crossbeam-doc/crossbeam/ https://aturon.github.io/crossbeam-doc/crossbeam/ And there's a good blog post explaining some other things the library does: https://aturon.github.io/blog/2015/08/27/epoch/ https://aturon.github.io/blog/2015/08/27/epoch/
- pcwalton 11y ago
  > Does C++ have the ability to safely share stack data without copying? I don't think so, but I'm not an expert. It does in the same sense that it's safe to do anything in C++. Virtually nothing in C++ is safe, but you can pretty easily do it.
  - zanny 11y ago
    Make the stack data const or wrap it in a mutex. That is what you end up having to do internally in Rust anyway, or being more sophisticated and having page locks.
    - steveklabnik 11y ago
      You can safely pass mutable pointers to stack data to scoped threads.
      - zanny 11y ago
        Which requires the language to perform some kind of synchronization around the data access or you will have races between threads. Just because you don't have to be explicit about it doesn't mean you don't need to have some mechanism to handle it somewhere, its just automatic instead.
        steveklabnik 11y ago
        It does not, actually, if you're accessing disjointed parts of your data: http://aturon.github.io/crossbeam-doc/crossbeam/struct.Scope.html#method.spawn http://aturon.github.io/crossbeam-doc/crossbeam/struct.Scope...
pcwalton 11y ago
> In that light, I have a question for you: What other concurrency features does Rust offer over C++ outside of data race freedom guarantees? I would say that the biggest win of Rust, once you get past the data race freedom, is that Rust's overall design puts the CSP model front and center like Erlang and Go do, while C++ is built on mutexes, locks, and futures. The way to get started with concurrent programming in Rust is thread::spawn, Sender, and Receiver, which will take you far. But C++ doesn't even have channels in the standard library; it encourages you to dive headfirst into shared memory, which makes simple concurrency needlessly difficult. Rust doesn't restrict you from using shared memory when you need to (and verifies that it's safe when you do). But Rust's libraries and ecosystem encourage you to design your apps in shared-nothing fashion first, and only to introduce memory sharing when you need it for performance. That's a much friendlier way to deal with concurrency than mutexes, locks, and futures.

dikaiosune 11y ago

Does C++ have the ability to safely share stack data without copying? I don't think so, but I'm not an expert. Rust has a few libraries that enable stack-scoped threads that are safe by virtue of ensuring that all threads created in the scope terminate before the data they reference is dropped (EDIT: and by preventing mutation of shared state without guarantees about atomic operations). For example, I'm working on a project that uses crossbeam: https://aturon.github.io/crossbeam-doc/crossbeam/ https://aturon.github.io/crossbeam-doc/crossbeam/ And there's a good blog post explaining some other things the library does: https://aturon.github.io/blog/2015/08/27/epoch/ https://aturon.github.io/blog/2015/08/27/epoch/

pcwalton 11y ago
> Does C++ have the ability to safely share stack data without copying? I don't think so, but I'm not an expert. It does in the same sense that it's safe to do anything in C++. Virtually nothing in C++ is safe, but you can pretty easily do it.
- zanny 11y ago
  Make the stack data const or wrap it in a mutex. That is what you end up having to do internally in Rust anyway, or being more sophisticated and having page locks.
  - steveklabnik 11y ago
    You can safely pass mutable pointers to stack data to scoped threads.
    - zanny 11y ago
      Which requires the language to perform some kind of synchronization around the data access or you will have races between threads. Just because you don't have to be explicit about it doesn't mean you don't need to have some mechanism to handle it somewhere, its just automatic instead.
      - steveklabnik 11y ago
        It does not, actually, if you're accessing disjointed parts of your data: http://aturon.github.io/crossbeam-doc/crossbeam/struct.Scope.html#method.spawn http://aturon.github.io/crossbeam-doc/crossbeam/struct.Scope...

pcwalton 11y ago

> In that light, I have a question for you: What other concurrency features does Rust offer over C++ outside of data race freedom guarantees? I would say that the biggest win of Rust, once you get past the data race freedom, is that Rust's overall design puts the CSP model front and center like Erlang and Go do, while C++ is built on mutexes, locks, and futures. The way to get started with concurrent programming in Rust is thread::spawn, Sender, and Receiver, which will take you far. But C++ doesn't even have channels in the standard library; it encourages you to dive headfirst into shared memory, which makes simple concurrency needlessly difficult. Rust doesn't restrict you from using shared memory when you need to (and verifies that it's safe when you do). But Rust's libraries and ecosystem encourage you to design your apps in shared-nothing fashion first, and only to introduce memory sharing when you need it for performance. That's a much friendlier way to deal with concurrency than mutexes, locks, and futures.