With .blocking mode, this example seems like it should operate differently.
var sendFrame = async send_message(addr);
// ... do something else while
// the message is being sent ...
try await sendFrame;
In .blocking mode there can be no parallelism, if I'm correctly interpreting what the compiler does.
Maybe the part that's different than what I expected is that it works like node with a single event loop rather than in Go where the number of parallel running goroutines defaults to the number of CPU hardware threads.
In .blocking mode, does `async send_message(addr)` spawn a new OS thread? If it does than you could still have parallelism (or at least concurrency, if I remember the difference between those two correctly).
can we please come up with something easier to grasp than async and await?
goroutines in Go make perfect sense to me and async and await do not. the article linked here explains why, perfectly, accidentally.
note that I am not saying that goroutines are perfect.
one of the code snippets shows code which invokes an async method, then shows where you could do other things before awaiting the result. how is this any different than just moving the other things before invoking the async method and using a synchronous method instead?
if your async method and your "other stuff" both take time over the network and can happen at the same time, how is this any better than coroutines? at least in Go, launching a goroutines is a single keyword, not two, like async and await.
there is value in being able to turn async off when you want, but what am I to do if I only want to turn it off for individual methods, and not all of them? I'm right back to changing all of those single methods and their invocations, manually. Go only requires me to change the invocation.
I posit that async/await is flawed inherently, even if any given person likes it and is accustomed to its problems.
why are TWO keywords needed? requiring a keyword at invocation and at return value assignment just impedes experimentation later, and would require two method definitions if you want both a synchronous and asynchronous version, right?
1. in node there's only a single thread (ignoring workers) but in Go the thing you start can run in parallel with the other stuff.
2. even in Go it's two operations, if you want to wait for the goroutine, you have to use a WaitGroup or similar and wait on it.
3. in Go you can't turn off the goroutines. Every call to a library function can potentially suspend the goroutine and resume later transparently (other than elapsed time).
I'm fine with the way Go works as well as the explicit Future or CompletionStage of Java where I can actually control which threads things run on. We'll have to see what happens with project Loom to see how well that works. I haven't used Kotlin coroutines to comment.
Async/await is just a callback flattened into the function body.
I.E.
var x = await foo();
var y = await doStuffWith(x);
return x + y;
Is equivalent to, in a less enlightened language...
foo().callback(x =>
doStuffWith(x).callback(y =>
x + y));
Goroutines are a more general feature in that channels can accept multiple inputs in sequence. But you can basically think of async/await as a special (the most commmon?) case of goroutines/channels, where the called goroutine sends back a single value on the channel as its one and only result.
Maybe the part that's different than what I expected is that it works like node with a single event loop rather than in Go where the number of parallel running goroutines defaults to the number of CPU hardware threads.