3 ms·
Do people really find CSP a good approach to concurrency? I've always thought that channels were a relatively poor choice of fundamental primitive -- channel-ba
by iainmerrick 8y ago
Do people really find CSP a good approach to concurrency? I've always thought that channels were a relatively poor choice of fundamental primitive -- channel-based concurrency is tricky to get right and not very composable.
Most viable concurrency primitives are in some sense equivalent (you can build condition variables out of channels and vice-versa, say) but that doesn't mean they're equally good.
Java has per-object "synchronized" and "notify" as its core constructs, but it's a bad idea to use those directly for day-to-day concurrency tasks. Much better to use library classes like ThreadPoolExecutor and Future.
In Go, do you tend to use channels directly, or do you use higher-level wrappers?
- apta 8y agoExactly. I get the feeling that people who claim golang gets concurrency right have not used the much more powerful constructs in the Java standard library. They keep getting better with things like CompletableFuture which was added in Java 8, and coroutines which are going to be added to the JVM sometime down the line by means of project Loom. Composability in golang concurrency constructs is non-existent. Having to manually manage channels to indicate errors, return values, and completion is error prone and does not compose, and is subject to race conditions. I don't see anything that I can do in golang that I wouldn't be able to do using Java's futures, while still being more composable and easier to reason about in Java.
- int_19h 8y agoI think composability especially is the key point. With futures (and async/await sugar on top), everything is naturally composable. It's much trickier with channels.