5 ms·
Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Though, I honestly find moderately complex Go co
by jchw 2y ago
Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be.
Though, I honestly find moderately complex Go code far easier to maintain than moderately complex RxJS code, having had both in my career at different times. That said I will admit that sometimes having the RxJS toolkit at your disposal makes solving some problems very easy. It's just that when I construct an RxJS pipeline that does some complex stuff end-to-end, don't expect me to be able to readily explain it a couple months later. It's not write-only... But it gets thick easily.
One issue I think people underrate that impacts both promises and RxJS is error handling. Exceptions in JS can be a lot of different things, including programming errors like TypeError; but most people will write error handling that doesn't actually distinguish the two cases. In fact it's hard to blame them as this can make for a lot of error-prone boilerplate to deal with, but it's especially annoying as it can hide programming errors in plain sight, making them hard to spot for your observability tooling and harder to debug (it's frequently not a possibility people give much thought to.)
Then again, on the Go end, I find it hard to try to handle async errors as well, though for totally different reasons. There's lots of good ideas floating around with Go and I even kind of like contexts to a degree, but it feels like there's no cohesive story that binds it all together. I used to use tomb, but I found myself wanting even more than it offered.
- phplovesong 2y agoI argue CSP is far superior to async/await in almost all cases. In Go errors are explicit and always right there. No weird control flow like you see in javascript.
- codethief 2y agoFor everyone else who, like me, needs to think for a moment to remember what CSP stands for: https://en.m.wikipedia.org/wiki/Communicating_sequential_processes https://en.m.wikipedia.org/wiki/Communicating_sequential_pro...
- dullcrisp 2y agoSo you prefer CSP to CPS?
- SkiFire13 2y agoCSP and async/await are perpendicular concepts. In fact you can have all combinations of them. Personally though I prefer either the actor model or structured concurrency to CSP, depending on the usecase.
- valenterry 2y agoI like a combination of both: actor model high level (basically, the business needs to understand the purpose/meaning of every actor) and then structured concurrency within each actor. I've been trying to convince the gleam folks of that without too much success so far...
- glenjamin 2y agoHow do you handle errors when reading from a channel?
- styluss 2y agodata, ok := <-someChan If ok is false, the channel is closed and data is a zero value.
- eknkc 2y agoWhenever I used channels in Go, I regretted it at the end. Always have to look up "what happens when I do x and the channel is closed" kind of stuff. Code becomes weird with all the selects and shit. I like sync primitives and good old collections.
- styluss 2y agoOh absolutely, whenever i use anything, I have to see how to integrate cancellation and now context is everywhere just for this. It gets overly verbose because of "simplicity"
- porridgeraisin 2y agoYeah, where I worked we rarely used channels directly in business logic. Most of our code looked like "do 5 different time consuming operations, some of them optional i.e can fail" and then combine them all appropriately depending on success/failure so we simply made a BoundedWaitGroup primitive using sync.WaitGroup and a channel to ensure the boundedness that gets used everywhere.
- the_gipsy 2y agoThere is no error here, just a closed channel (e.g. finished successfully is indistinguishable). You do need to use either two channels (horrible code) or some kind of Result{T,error} wrapper (bad language design).
- cyberax 2y ago> Concurrency in Go is overrated; channels are error-prone and not as flexible as they probably could/should be. Channels in Go indeed could be better designed and more extensible. However, they are not the only way to use the Go concurrency. There are usual condition variables, mutexes, etc.
- jchw 2y agoYep, and frankly I often find myself writing traditional concurrency code in Go. gVisor's checklocks analyzer can be very useful.