27 ms·

Async/await is syntactic burden. In golang, everything is async so there is no need to differentiate between async/sync methods. Goroutines = coroutines with i

Async/await is syntactic burden. In golang, everything is async so there is no need to differentiate between async/sync methods. Goroutines = coroutines with implicit await on every function call > And somehow people are ok with it, and say it is simple. Threads and queues are (IMHO) fairly easy to understand and work with. If you know how you'd write an application with threads and queues, goroutines and channels work pretty much the same way.

pkolaczk 4y ago
It is not a syntactic burden, because it provides valuable information to the code reader. It is very important to me that I can quickly spot all places where execution can wait. For example, the user interface should take that into account, because noone likes programs that freeze temporarily waiting on something. Also, await points are places where execution can jump threads - this is critical to thread safety analysis. Making them invisible in a language that doesn't offer reliable data race detection is a similar idea like making types invisible in a language with dynamic and weak typing. And finally a model where await is implicit and automatically inserted by the compiler/runtime is less expressive (more limited) than async/await. For instance you wouldn't be able to do this if await was automatically inserted on each async thing, because they'd run sequentially and I don't want to: let future1 = do_one_async_thing(); let future2 = do_another_async_thing(); let (res1, res2) = join!(future1, future2); > Threads and queues are (IMHO) fairly easy to understand and work with 1. Sure, goto is easier to understand than for loops, ifs and functions. And it has its place, and I agree sometimes it can make things simpler. But I wouldn't want to work in a language where it is the only control flow construct. 2. Threads and queues are present in Rust as well, so that's not the reason Go could have an edge here.
- bheadmaster 4y ago
  > It is not a syntactic burden, because it provides valuable information to the code reader "Valuable" is subjective. I personally find async/await annotations annoying and pointless, and even leading to subtle bugs if you forget to put an "await" in the right place. Code should not depend on questions like "how long will this method run". > Making them invisible in a language that doesn't offer reliable data race detection is a similar idea like making types invisible in a language with dynamic and weak typing. Golang has a race detector: https://go.dev/blog/race-detector https://go.dev/blog/race-detector > For instance you wouldn't be able to do this if await was automatically inserted on each async thing, because they'd run sequentially and I don't want to You can do that in Golang with channels: ch1 := make(chan ResultType1) ch2 := make(chan ResultType2) go do_one_async_thing(ch1) go do_another_async_thing(ch2) res1 := <-ch1 res2 := <-ch2 To me, this approach is much more intuitive because communication happens explicitly through a channel, instead of implicitly through a Future that is magically returned from async functions if you don't put "await". > Sure, goto is easier to understand than for loops, ifs and functions. And it has its place, and I agree sometimes it can make things simpler. This is a dishonest take. Threads and queues are the most basic concurrent mechanisms, and async/await just emulates threads of execution in userspace. Golang does that too. The only difference is the lack of special syntax, and channels are used for inter-task communication instead of Futures. > Threads and queues are present in Rust as well, so that's not the reason Go could have an edge here. Threads in Rust are OS threads, and they are heavy. That's why the whole "async" world exists in the first place - because launching many OS threads slows down your system and takes up lot of memory. Go takes the execution model of threads, and emulates them in userspace with implicit async runtime, so they are much faster and take much less memory.
  - pkolaczk 4y ago
    > async/await annotations (...) leading to subtle bugs if you forget to put an "await" in the right place In most cases if you forget to call them, the return type would be different and it would be caught by the compiler as a hard error. And if you don't use a result of something important that also leads to a warning. However, I partially agree here with you - I can see this could lead to a potential problem when you rely on side-effects of a function that doesn't return anything. But a side effecting, async, infallible function that doesn't return anything (so it doesn't return potentially an Err) is IMHO quite a weird thing in this world. You're much better off spawning a task in such case. And spawned tasks are executed eagerly, they don't have to be awaited to run. > Golang has a race detector: https://go.dev/blog/race-detector https://go.dev/blog/race-detector Which works only at runtime and detects only some races. https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/ > To me, this approach is much more intuitive because communication happens explicitly through a channel... So an occasional single await here and there is a syntactic burden, but having to create explicit channels to communicate the results back, instead of using function return values, is suddenly not a syntactic burden? Not mentioning a performance impact of it. You need to allocate those queues, allocate those cross-thread communication channels and then let the runtime synchronize the communication properly, and also beware of the fact that your coroutines execute in parallel (not just concurrently) and the risk of data races is higher. > async/await just emulates threads of execution in userspace Technically yes, but the way one program with async/await is fundamentally different than programming with threads. It is a much more structured and high level approach. The data flow is basically the same as with normal sync calls - I run some async code, I get results back as standard function return. Channels offer a lot more flexibilty, I can have a channel that delivers data from arbitrary point of thread A to arbitrary point of thread B. Very much like goto can jump from arbitrary point A to point B. See: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... > Threads in Rust are OS threads, and they are heavy. Actually OS threads are suprprisingly fast and lightweight these days and this claim could be challenged. I've seen many threaded programs outperform programs using async and there are probably quite few usecases where green threads would offer significant performance advantage. The difference is you're scheduling them in userspace vs kernelspace, but you're still scheduling them blindly, and you still need the same synchronization primitives to coordinate the threads. And that coordination is expensive. Spawning a green thread (a task on a threadpool) running it and returning a result over an MPSC queue is still orders of magnitude slower than modifying a variable on caller's stack directly (which Rust async/await often reduces to). But anyway, Rust has also green threads. Just use tokio::spawn + channels and those are your lightweight threads just as in Go.

pkolaczk 4y ago

It is not a syntactic burden, because it provides valuable information to the code reader. It is very important to me that I can quickly spot all places where execution can wait. For example, the user interface should take that into account, because noone likes programs that freeze temporarily waiting on something. Also, await points are places where execution can jump threads - this is critical to thread safety analysis. Making them invisible in a language that doesn't offer reliable data race detection is a similar idea like making types invisible in a language with dynamic and weak typing. And finally a model where await is implicit and automatically inserted by the compiler/runtime is less expressive (more limited) than async/await. For instance you wouldn't be able to do this if await was automatically inserted on each async thing, because they'd run sequentially and I don't want to: let future1 = do_one_async_thing(); let future2 = do_another_async_thing(); let (res1, res2) = join!(future1, future2); > Threads and queues are (IMHO) fairly easy to understand and work with 1. Sure, goto is easier to understand than for loops, ifs and functions. And it has its place, and I agree sometimes it can make things simpler. But I wouldn't want to work in a language where it is the only control flow construct. 2. Threads and queues are present in Rust as well, so that's not the reason Go could have an edge here.

bheadmaster 4y ago
> It is not a syntactic burden, because it provides valuable information to the code reader "Valuable" is subjective. I personally find async/await annotations annoying and pointless, and even leading to subtle bugs if you forget to put an "await" in the right place. Code should not depend on questions like "how long will this method run". > Making them invisible in a language that doesn't offer reliable data race detection is a similar idea like making types invisible in a language with dynamic and weak typing. Golang has a race detector: https://go.dev/blog/race-detector https://go.dev/blog/race-detector > For instance you wouldn't be able to do this if await was automatically inserted on each async thing, because they'd run sequentially and I don't want to You can do that in Golang with channels: ch1 := make(chan ResultType1) ch2 := make(chan ResultType2) go do_one_async_thing(ch1) go do_another_async_thing(ch2) res1 := <-ch1 res2 := <-ch2 To me, this approach is much more intuitive because communication happens explicitly through a channel, instead of implicitly through a Future that is magically returned from async functions if you don't put "await". > Sure, goto is easier to understand than for loops, ifs and functions. And it has its place, and I agree sometimes it can make things simpler. This is a dishonest take. Threads and queues are the most basic concurrent mechanisms, and async/await just emulates threads of execution in userspace. Golang does that too. The only difference is the lack of special syntax, and channels are used for inter-task communication instead of Futures. > Threads and queues are present in Rust as well, so that's not the reason Go could have an edge here. Threads in Rust are OS threads, and they are heavy. That's why the whole "async" world exists in the first place - because launching many OS threads slows down your system and takes up lot of memory. Go takes the execution model of threads, and emulates them in userspace with implicit async runtime, so they are much faster and take much less memory.
- pkolaczk 4y ago
  > async/await annotations (...) leading to subtle bugs if you forget to put an "await" in the right place In most cases if you forget to call them, the return type would be different and it would be caught by the compiler as a hard error. And if you don't use a result of something important that also leads to a warning. However, I partially agree here with you - I can see this could lead to a potential problem when you rely on side-effects of a function that doesn't return anything. But a side effecting, async, infallible function that doesn't return anything (so it doesn't return potentially an Err) is IMHO quite a weird thing in this world. You're much better off spawning a task in such case. And spawned tasks are executed eagerly, they don't have to be awaited to run. > Golang has a race detector: https://go.dev/blog/race-detector https://go.dev/blog/race-detector Which works only at runtime and detects only some races. https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/ > To me, this approach is much more intuitive because communication happens explicitly through a channel... So an occasional single await here and there is a syntactic burden, but having to create explicit channels to communicate the results back, instead of using function return values, is suddenly not a syntactic burden? Not mentioning a performance impact of it. You need to allocate those queues, allocate those cross-thread communication channels and then let the runtime synchronize the communication properly, and also beware of the fact that your coroutines execute in parallel (not just concurrently) and the risk of data races is higher. > async/await just emulates threads of execution in userspace Technically yes, but the way one program with async/await is fundamentally different than programming with threads. It is a much more structured and high level approach. The data flow is basically the same as with normal sync calls - I run some async code, I get results back as standard function return. Channels offer a lot more flexibilty, I can have a channel that delivers data from arbitrary point of thread A to arbitrary point of thread B. Very much like goto can jump from arbitrary point A to point B. See: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... > Threads in Rust are OS threads, and they are heavy. Actually OS threads are suprprisingly fast and lightweight these days and this claim could be challenged. I've seen many threaded programs outperform programs using async and there are probably quite few usecases where green threads would offer significant performance advantage. The difference is you're scheduling them in userspace vs kernelspace, but you're still scheduling them blindly, and you still need the same synchronization primitives to coordinate the threads. And that coordination is expensive. Spawning a green thread (a task on a threadpool) running it and returning a result over an MPSC queue is still orders of magnitude slower than modifying a variable on caller's stack directly (which Rust async/await often reduces to). But anyway, Rust has also green threads. Just use tokio::spawn + channels and those are your lightweight threads just as in Go.