5 ms·
I 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 javascri
by phplovesong 2y ago
I 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).