Hacker News new | ask | show | jobs
by morelisp 1066 days 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.

1 comments

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.
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.

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