With .blocking mode, this example seems like it should operate differently.<p><pre><code> var sendFrame = async send_message(addr);
// ... do something else while
// the message is being sent ...
try await sendFrame;
</code></pre>
In .blocking mode there can be no parallelism, if I'm correctly interpreting what the compiler does.<p>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.
can we <i>please</i> come up with something easier to grasp than async and await?<p>goroutines in Go make perfect sense to me and async and await do not. the article linked here explains why, perfectly, accidentally.<p>note that I am not saying that goroutines are perfect.<p>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?<p>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.<p>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.<p>I posit that async/await is flawed inherently, even if any given person likes it and is accustomed to its problems.<p>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?