4 ms·
> Green threads aren’t easier than async functions. The function colors don’t go away Don't they? Using green threads I can happily call a blocking function in
by assbuttbuttass 3y ago
> Green threads aren’t easier than async functions. The function colors don’t go away
Don't they? Using green threads I can happily call a blocking function in a synchronous context in one place, and run it with a goroutine in another place.
With async (particularly Rust's tokio), you need to pass around the "runtime" object in order to call an async function in a synchronous context.
- BreakfastB0b 3y agoGo functions are coloured as well. context.Context proliferates everywhere IO takes place to handle cancellation / short circuiting because goroutines can’t be sent signals to die like threads. They have to exit themselves.
- SPBS 3y agoNot really. A context-less function can call a contextual one by passing in a context.Background(), and a contextual function can call a context-less one by leaving out the context. This is unlike the split between sync/async.
- derefr 3y ago> A context-less function can call a contextual one by passing in a context.Background() Yeah, but if you're calling passing context.Background() because the caller's caller had a context but you can't access it through the context-less caller, now you've got a "synchronicity leak" (a.k.a. "the program won't gracefully shut down when I press ^C.") Golang's concurrency is an abstract machine model whose soundness you need to enforce yourself, because the compiler doesn't care about it. If the compiler actually cared about enforcing the concurrency model, writing code like the you're describing would fail to compile, due to function coloring.
- rowanG077 3y agoBy that definition there is also no function coloring in rust. Since you can just create an ad hoc executor.