3 ms·
CSP with channels in Go is just a fancy locking mechanism, something that Rob Pike and co wanted to experiment with, and a marketing feature, of course. Nothing
by zzzcpan 11y ago
CSP with channels in Go is just a fancy locking mechanism, something that Rob Pike and co wanted to experiment with, and a marketing feature, of course. Nothing more. They don't really work that well. Their limitations, verbosity and quite complex implicit behavior makes them hard to use for high level things. I think mutexes are more widespread and more encouraged already in Go, than channels. So, idiomatically and in the standard library Go doesn't handle concurrency well at all, on the opposite, it has the worst kind of concurrency - shared memory multithreading. And anything can be better than that. Even a wrapper around synchronous APIs ;)
It doesn't mean, of course, that Swift or any other language will be a Go killer. It means that most people never write complex concurrent programs to begin with and don't really care about good concurrency models. Sadly or luckily, this applies to people, who design languages as well, so concurrency tend to be a hype-driven mess. The only known exception is Erlang, where the whole language was designed to solve concurrency problems.
- lobster_johnson 11y agoI agree. I've found Go channels to be disappointing in practice. There's lots of PR but little criticism of something so key. The fact that they are implemented using mutexes is, from my admittedly limited, non-concurrency-expert perspective, inexplicable. The simplest use case, an unbuffered channel, should be trivial to implement using CAS. There's a bunch of research on implementing robust queues using CAS. Then there are the various ugly edge cases: Closing a closed channel is an error (now you have to implement your own refcounting implementation if you want to hand out a single channel to multiple consumers), receive on nil channel blocks (means you can't use nil as a signal to mean "I've closed the channel"), etc. I really like GCD's style of enqueueing concurrent tasks, which I think is a concurrency model that often works more naturally than channels. A major difference between GCD and goroutines is that you can specify what queue to use. I'm looking forward to see what they come up with for Swift.
- danappelxx 11y agoI think that Go's biggest mistake was making goroutines multithreaded. Libmill takes a much safer approach by making everything still run on one thread (and by taking advantage of libmill, Venice brings a similar scheme but with the added safety).