5 ms·

> 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

> 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

morelisp 3y ago
Ad absurdum, then anything other than full curried 1-ary-exclusive functions is 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.
- mcronce 3y ago
  Not sure about in Python, but in Rust, you can easily bridge sync and async code. The function coloring problem is, at least in that case, grossly overstated.
  - throwaway2037 3y ago
    Why was this downvoted? The person makes an interesting point. For discussion, can you please provide a short sample in Rust to demonstrate your point? I would like to hear more.
    - mcronce 3y ago
      I'm guessing it was downvoted for mentioning Rust ¯\_(ツ)_/¯ 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()); } There is _a bit_ of ceremony required to bridge the two, but it's pretty minimal. If you want to know more about any of that, happy to explain or provide links for further reading
Kamq 3y ago
Is it really? >90% of the time, I'm just passing a context so that I can cancel the rest of the goroutines if an early one fails and I don't need to do the rest of the computation. That works just fine with throwing a context.Background in, which should be available anywhere, and not color the function.

> 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

morelisp 3y ago

Ad absurdum, then anything other than full curried 1-ary-exclusive functions is 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.

mcronce 3y ago
Not sure about in Python, but in Rust, you can easily bridge sync and async code. The function coloring problem is, at least in that case, grossly overstated.
- throwaway2037 3y ago
  Why was this downvoted? The person makes an interesting point. For discussion, can you please provide a short sample in Rust to demonstrate your point? I would like to hear more.
  - mcronce 3y ago
    I'm guessing it was downvoted for mentioning Rust ¯\_(ツ)_/¯ 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()); } There is _a bit_ of ceremony required to bridge the two, but it's pretty minimal. If you want to know more about any of that, happy to explain or provide links for further reading

Kamq 3y ago

Is it really? >90% of the time, I'm just passing a context so that I can cancel the rest of the goroutines if an early one fails and I don't need to do the rest of the computation. That works just fine with throwing a context.Background in, which should be available anywhere, and not color the function.