4 ms·

About 6 or 7 years ago I was searching for a language that had great concurrency built in and a sane enough model of concurrency that would allow me to get thin

About 6 or 7 years ago I was searching for a language that had great concurrency built in and a sane enough model of concurrency that would allow me to get things done. Eventually I found and fell in love with gevent because I could write fairly straightforward code in a synchronous fashion and reason about the code a lot easier than other models. But then I found some warts with gevent: what about good community support? What about exploiting parallelism? Monkey patching 3rd party libs is a bit ugly and not 100% without faults. So imagine how I felt when I found that Go offers this model of concurrency CSP with support for parallelism due to the M to N threading model. Also a not quite but close enough Python looking syntax and at that point I never looked back. Sure there other models of concurrency and other languages that are also proving to be useful. But Go has been a good bet...at least for now. And I know this is controversial...but Go’s time is running out...other languages are getting there with more advanced support for asynchronous programming...so I imagine in due time I’ll be onto the next thing.

yingw787 7y ago
Hey thanks for commenting and sharing! My experience with golang was pretty short; this was back in the days of `go get` and I just couldn't get used to the dependency management system. I think others have had the same problem: https://bluxte.net/musings/2018/04/10/go-good-bad-ugly https://bluxte.net/musings/2018/04/10/go-good-bad-ugly IMHO a language is a combination of different factors: the community, the spec, the libraries, the support, the toolchain, etc. and the concurrency model is only one small part of that. If your concurrency model is CSP, the truer that statement may be, because CSP allows you to write highly stateful code, and because given time all user code trends towards the properties of the language and CSP doesn't really enforce a whole lot.
melan13 7y ago
Chapel programming language has been around a long time
bjoli 7y ago
Guile has a full implementation of parallel concurrent ML which is similar, but not quite the same as go. It is implemented as a library over pthreads and delimited continuations, and it is amazing. The largest difference is that channels are unbuffered.

yingw787 7y ago

Hey thanks for commenting and sharing! My experience with golang was pretty short; this was back in the days of `go get` and I just couldn't get used to the dependency management system. I think others have had the same problem: https://bluxte.net/musings/2018/04/10/go-good-bad-ugly https://bluxte.net/musings/2018/04/10/go-good-bad-ugly IMHO a language is a combination of different factors: the community, the spec, the libraries, the support, the toolchain, etc. and the concurrency model is only one small part of that. If your concurrency model is CSP, the truer that statement may be, because CSP allows you to write highly stateful code, and because given time all user code trends towards the properties of the language and CSP doesn't really enforce a whole lot.

melan13 7y ago

Chapel programming language has been around a long time

bjoli 7y ago

Guile has a full implementation of parallel concurrent ML which is similar, but not quite the same as go. It is implemented as a library over pthreads and delimited continuations, and it is amazing. The largest difference is that channels are unbuffered.