3 ms·

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then ma

by RX14 9y ago

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

62747478182 9y ago
go-style csp is just async/await hidden in the syntax.
- RX14 9y ago
  It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.
dbaupp 9y ago
Async/await can be cheaper given other constraints, e.g. Go ends up using a lot of GC infrastructure to keep stacks small/minimize memory use, which makes FFI to C-style languages expensive. If syntax is all that matters, then sequential code is great, but there's more than that for many tasks. (In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)
lmm 9y ago
With async/await you can tell from the type signature whether a given function might suspend, and then reading through the body you can see whether each function call is a non-suspending one or a possibly-suspending one. It makes it really obvious what's doing what. If suspension is your only effect then it probably doesn't matter (one unmanaged effect is ok), but when you have other effects that might interact, having all the suspension points be explicit is really useful. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html gives one example.
- RX14 9y ago
  Thanks, yeah, that's a useful insight. I guess it's rather a moot point with Go anyway since you have multiple goroutines executing on multiple cores at once.
zbentley 9y ago
There are technical benefits and drawbacks to both approaches. I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors. You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.
kazagistar 9y ago
Go has a lot of complexity and slowdown around FFI due to all the internal context switching, locking, and stack management. Even if there are benefits for this use case, for such a drawback is not acceptable for a systems language intended for embedding and low level libraries.

by RX14 9y ago

62747478182 9y ago

go-style csp is just async/await hidden in the syntax.

RX14 9y ago
It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.

dbaupp 9y ago

Async/await can be cheaper given other constraints, e.g. Go ends up using a lot of GC infrastructure to keep stacks small/minimize memory use, which makes FFI to C-style languages expensive. If syntax is all that matters, then sequential code is great, but there's more than that for many tasks. (In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)

lmm 9y ago

With async/await you can tell from the type signature whether a given function might suspend, and then reading through the body you can see whether each function call is a non-suspending one or a possibly-suspending one. It makes it really obvious what's doing what. If suspension is your only effect then it probably doesn't matter (one unmanaged effect is ok), but when you have other effects that might interact, having all the suspension points be explicit is really useful. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html gives one example.

RX14 9y ago
Thanks, yeah, that's a useful insight. I guess it's rather a moot point with Go anyway since you have multiple goroutines executing on multiple cores at once.

zbentley 9y ago

There are technical benefits and drawbacks to both approaches. I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors. You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.

kazagistar 9y ago

Go has a lot of complexity and slowdown around FFI due to all the internal context switching, locking, and stack management. Even if there are benefits for this use case, for such a drawback is not acceptable for a systems language intended for embedding and low level libraries.