4 ms·

I think this was truly the most amazing thing about learning Rust. After having experienced the pain (the issues brought up in the linked slide deck) of threads

I think this was truly the most amazing thing about learning Rust. After having experienced the pain (the issues brought up in the linked slide deck) of threads in C, then C++ and Java, it was wild to work with a language that provided some significant safety rails for working with data across threads. Now async/await gives us even better options on top of that, but it’s truly what made me enjoy the language so much. This article is what resonated with me and got me to invest so much spare time over the last 5 years in working with Rust: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

BubRoss 7y ago
I think the idea that finding ways of working with threads (and ownership) with more safety while minimizing performance impact is a healthy side effect of rust. I think though that rust is one approach of many and that they aren't orthogonal. I personally think libraries for multi threading on top of rust or C++ are necessary to really nail the problem down. Even async and await are too granular and difficult to get right in my opinion. I think regardless of the language, queues of data chunks (not just tasks) combined with solid concurrent data structures will go a very long way. Rust may help get those libraries and data structures to be more correct with less effort, but ultimately getting threading right at the lower level just isn't practical for most programmers most of the time, and I say this as someone confident in their parallel programming skills.
- acheron9383 7y ago
  Yeah, there are some pretty solid crates coming up. Obviously Tokio as a runtime, Rayon for parallel iterators,and the whole Async Std crate. Rayon is a good example of a crate that helps add concurrency without much headache for embarrassingly parallel operations. Even still, even in languages with built-in runtimes and GC like GO, it is very easy to create deadlocks/livelocks. Programmers intuitions of concurrency are generally wrong, and the correct intuitions are complex. I don't know how we make concurrency easy. I do like Futures however, they provide a nice abstraction over threads.
  - senderista 7y ago
    I'm gonna be That Guy and point out that rayon addresses parallelism, not concurrency (which is crossbeam's domain). My favorite explanation of the difference (by the inimitable yosefk): https://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html https://yosefk.com/blog/parallelism-and-concurrency-need-dif....
    - acheron9383 7y ago
      Was an interesting read, thanks! Excited for the future where now I can become That Guy™!
gmfawcett 7y ago
Rust does a great job here, but so do languages that make multithreading safer at a higher level -- Erlang/OTP and Haskell are two great examples. Immutable data may not solve every concurrency problem, but it sure goes a long way. I also have a lot of respect for Ada's task-based concurrency approach (independent actors, communicating by rendezvous). You don't get the flexibility to roll your own concurrency strategy in Ada, but the language's support for its chosen mechanism is truly excellent. Even if you'll never use Ada, this part of the language is worth studying just as an example of great engineering design.
- DougBTX 7y ago
  There's a nice Kevlin Henney talk where he lays out this diagram: | non-shared mutable state | shared mutable state | ----------------------------+------------------------ | non-shared immutable state | shared immutable state | Each quadrant is safe, except the one in the top right: shared mutable state. Functional languages are great at the bottom two, since they strongly encourage immutable state. Message-passing based concurrency strongly encourages non-shared state, the safe two on the left. Rust is the only language I've seen which encourages all three safe quadrants, while making the fourth a compile-time error.
  - redisman 7y ago
    Speaking of Shared mutable state, unlearning OOP is going to be a big task for the industry to tackle. Feels like it's on its way out on the backend at least already. It's definitely been my biggest stumbling block in grokking parallel compute.
  - whateveracct 7y ago
    > Functional languages are great at the bottom two, since they strongly encourage immutable state. Haskell actually has safe & ergonomic shared mutable state via STM And it has proven-to-be-not-shared mutable state via ST.
  - kccqzy 7y ago
lmilcin 7y ago
I still feel that, while all these abstractions are very fine and handy, there is only so much you can do without actually understanding how threading and locking works. If you grow up as a developer without actually touching it I wonder how you can actually understand this.

BubRoss 7y ago

I think the idea that finding ways of working with threads (and ownership) with more safety while minimizing performance impact is a healthy side effect of rust. I think though that rust is one approach of many and that they aren't orthogonal. I personally think libraries for multi threading on top of rust or C++ are necessary to really nail the problem down. Even async and await are too granular and difficult to get right in my opinion. I think regardless of the language, queues of data chunks (not just tasks) combined with solid concurrent data structures will go a very long way. Rust may help get those libraries and data structures to be more correct with less effort, but ultimately getting threading right at the lower level just isn't practical for most programmers most of the time, and I say this as someone confident in their parallel programming skills.

acheron9383 7y ago
Yeah, there are some pretty solid crates coming up. Obviously Tokio as a runtime, Rayon for parallel iterators,and the whole Async Std crate. Rayon is a good example of a crate that helps add concurrency without much headache for embarrassingly parallel operations. Even still, even in languages with built-in runtimes and GC like GO, it is very easy to create deadlocks/livelocks. Programmers intuitions of concurrency are generally wrong, and the correct intuitions are complex. I don't know how we make concurrency easy. I do like Futures however, they provide a nice abstraction over threads.
- senderista 7y ago
  I'm gonna be That Guy and point out that rayon addresses parallelism, not concurrency (which is crossbeam's domain). My favorite explanation of the difference (by the inimitable yosefk): https://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html https://yosefk.com/blog/parallelism-and-concurrency-need-dif....
  - acheron9383 7y ago
    Was an interesting read, thanks! Excited for the future where now I can become That Guy™!

gmfawcett 7y ago

Rust does a great job here, but so do languages that make multithreading safer at a higher level -- Erlang/OTP and Haskell are two great examples. Immutable data may not solve every concurrency problem, but it sure goes a long way. I also have a lot of respect for Ada's task-based concurrency approach (independent actors, communicating by rendezvous). You don't get the flexibility to roll your own concurrency strategy in Ada, but the language's support for its chosen mechanism is truly excellent. Even if you'll never use Ada, this part of the language is worth studying just as an example of great engineering design.

DougBTX 7y ago
There's a nice Kevlin Henney talk where he lays out this diagram: | non-shared mutable state | shared mutable state | ----------------------------+------------------------ | non-shared immutable state | shared immutable state | Each quadrant is safe, except the one in the top right: shared mutable state. Functional languages are great at the bottom two, since they strongly encourage immutable state. Message-passing based concurrency strongly encourages non-shared state, the safe two on the left. Rust is the only language I've seen which encourages all three safe quadrants, while making the fourth a compile-time error.
- redisman 7y ago
  Speaking of Shared mutable state, unlearning OOP is going to be a big task for the industry to tackle. Feels like it's on its way out on the backend at least already. It's definitely been my biggest stumbling block in grokking parallel compute.
- whateveracct 7y ago
  > Functional languages are great at the bottom two, since they strongly encourage immutable state. Haskell actually has safe & ergonomic shared mutable state via STM And it has proven-to-be-not-shared mutable state via ST.
- kccqzy 7y ago

lmilcin 7y ago

I still feel that, while all these abstractions are very fine and handy, there is only so much you can do without actually understanding how threading and locking works. If you grow up as a developer without actually touching it I wonder how you can actually understand this.