5 ms·

So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true?

So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.

rtpg 7y ago
Based on that description (haven't used D), it seems to cover similar grounds. But Rust's move semantics means that for message passing in particular you can protect against "use after send" issues. https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html
falcolas 7y ago
Frankly, not that much. Rust can primarily protect against memory usage race conditions, it can't catch most kinds of deadlocks or other concurrency issues.
- fluffything 7y ago
  Notice that Rust locks support dead-lock detection at run-time. You just need to enable the detection manually because it adds a run-time cost.
fluffything 7y ago
> How much better can it be? Rust guarantees that a data-race is a compilation error. D.. does not guarantee anything.. a data-race won't even give you a run-time error.. So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better. FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).
- 0xffff2 7y ago
  There's a lot more to correct concurrency than data races, although they are a big factor. I think it's more fare to say that going from D to Rust is going from zero to some guarantees. Still technically infinitely better.
jerf 7y ago
"So far, only Rust has a good story on concurrency thanks to its type system." In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter. There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.) This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.
mapgrep 7y ago
Doesn't Clojure have a pretty good concurrency story as well? (Which I find particularly relevant since it is a Lisp.)
- ilikehurdles 7y ago
  Yes it does. Writing concurrent code in Clojure out of the box is a blast, and for the more advanced use cases there's core.async.

rtpg 7y ago

Based on that description (haven't used D), it seems to cover similar grounds. But Rust's move semantics means that for message passing in particular you can protect against "use after send" issues. https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html

falcolas 7y ago

Frankly, not that much. Rust can primarily protect against memory usage race conditions, it can't catch most kinds of deadlocks or other concurrency issues.

fluffything 7y ago
Notice that Rust locks support dead-lock detection at run-time. You just need to enable the detection manually because it adds a run-time cost.

fluffything 7y ago

> How much better can it be? Rust guarantees that a data-race is a compilation error. D.. does not guarantee anything.. a data-race won't even give you a run-time error.. So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better. FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).

0xffff2 7y ago
There's a lot more to correct concurrency than data races, although they are a big factor. I think it's more fare to say that going from D to Rust is going from zero to some guarantees. Still technically infinitely better.

jerf 7y ago

"So far, only Rust has a good story on concurrency thanks to its type system." In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter. There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.) This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.

mapgrep 7y ago

Doesn't Clojure have a pretty good concurrency story as well? (Which I find particularly relevant since it is a Lisp.)

ilikehurdles 7y ago
Yes it does. Writing concurrent code in Clojure out of the box is a blast, and for the more advanced use cases there's core.async.