Which isn’t the comparison I’m replying to here. Calling an asynchronous function with “await” forces it to behave synchronously. You would only do such a thing if you were operating in a framework or language with colored functions.
> in C# or Java or even C++ you can chose between using that OR asynchronous code with futures.
Java, C#, and C++ have channels?
I don't really think you are right. When you await an async function, you let the async function run asynchronously, but suspend your own execution until you can receive the result from that function (an actual return value, an exception, or simply termination for void functions).
Calling a function directly forces it to run on the same execution thread as you. Calling it with await allows it to run in any thread. This is the actual advantage, and Go doesn't have any equivalent construct that is as convenient for this use case.
Also, note that a function that expects to return data through channels can't be called in a sync manner in Go or it will deadlock. So in essence there is function coloring in Go as well.
> Java, C#, and C++ have channels?
Not out of the box, but they are easy to replicate if desired, wrapping a lock in a send/receive interface (you can add a buffer as well if desired). It is probably not as efficient, but it may not be vastly different either.
OK so Thread A calls “await” on a coroutine that executes in Thread B (where B may or may not be A). Thread A is now blocked on that coroutine. What have I gained by running that coroutine in Thread B?
One potential answer is that while Thread A is blocked by “await”, it can context-switch to a different coroutine. You can effectively do similar things in Go if you want to. But doing so abandons the guarantee that Thread A will pick up where it left off as soon as Thread B is finished.
> Also, note that a function that expects to return data through channels can't be called in a sync manner in Go or it will deadlock. So in essence there is function coloring in Go as well.
Is this a popular or idiomatic interface for Go library code to the same degree it is for “async” libraries in other languages?
In isolation I find it more understandable to do channel writes as an explicit side effect than to manage futures but maybe that’s just my brain.
> Not out of the box, but they are easy to replicate if desired
I’m pretty sure you could implement futures and async/await using Go channels too if you wanted to.
Futures, maybe (though without generics you'll be either very dynamic or write a new future for each struct, of course).
But async/await is a syntactic feature and can't be implemented in a language without macros and/or continuations. Basically `await` is a keyword which returns a future that will execute the rest of the function as written. Something like this is relatively easy to implement:
async Task<int> Foo() {
int i := await Bar();
return i + 1;
}
func Foo() func()(int){
var reply chan int
go func() {
reply <- Bar()
}
return func()(int) {
i := <- reply
return i
}
}
async Task<int> Foo() {
auto sum = 0;
foreach (auto x in someEnumerable) {
switch(x) {
case 1:
sum += await Bar(x);
goto case 2;
case 2:
sum /= await Bar(x);
break;
}
}
return sum;
}
If the task that bar() will return is created when you first call it, then you're right, we didn't gain much. However, the task may have already been running for a long time behind the scenes, we may have done things in parallel with that run, and now that we need the result, we can block.
For example:
myHttpClient.StartReq1()
myHttpClient.StartReq2()
auto Res1 = await myHttpClient.WaitReq1()
auto res2 = await myHttpClient.WaitReq2()
Given the lack of generics, you would get a much worse interface. Btw, here is what a non-buffering channel would look like in Java:
class Channel<T> {
T value;
void publish(T value) {
synchronized(this) {
this.value = value;
try {
this.wait();
} catch (InterruptedException e) {}
}
}
T consume() {
synchronized(this) {
this.notify();
return this.value;
}
}
}Yeah they do but without green threads the implications are a bit different. You can use channels and OS threads though most code bases don't.