> The go keyword nicely prevents the annoying function coloring problem
FYI when you write a goroutine and have to use Context, that's literally just function coloring
FYI when you write a goroutine and have to use Context, that's literally just function coloring
You can easily bridge context-using and non-context-using code, you can have nested contexts, you can have multiple unrelated contexts, you can ignore the context, probably most critically you can't pass values back up the context, I don't see any way these look like function coloring.
For discussion, can you please provide a short sample in Rust to demonstrate your point? I would like to hear more.
For sure - it's a little terse, just to demonstrate the various cases
async fn do_something_async() {
nonblocking_sync_call();
tokio::task::spawn_blocking(blocking_sync_call()).await;
async_std::task::spawn_blocking(blocking_sync_call()).await;
async_call().await;
}
fn do_something_sync() {
nonblocking_sync_call();
blocking_sync_call();
futures::executor::block_on(async_call());
}
If you want to know more about any of that, happy to explain or provide links for further reading
That works just fine with throwing a context.Background in, which should be available anywhere, and not color the function.