[throwitaway1123]

> I also don't like how async/await ends up taking over a whole codebase. Often making one function async will cause you to update other functions to be async so you can do proper awaiting.

This is basically the function coloring problem. There was some ardent discussion about this a few weeks ago on HN [1], where the top comment positioned function coloring as a feature, because it highlights where expensive operations like IO might potentially be happening in your application.

I saw a comment recently where someone pointed out an old API in Java where comparing two URLs for equality initiates a DNS request, and so something as simple as putting a URL in a hash table could end up involving a network request [2]. So maybe it's reasonable to color functions that connect to the network at the very least. If I used a URL comparison library and it returned a promise it would immediately set off alarms in my mind.

[1] https://news.ycombinator.com/item?id=41001951

[2] https://news.ycombinator.com/item?id=41143458

[phyrex]

That could be much better solved through coeffects, but unfortunately most languages don’t support that. Doesn’t mean using async functions is a good way for this either

[throwitaway1123]

> That could be much better solved through coeffects

It's possible, but I can't thoroughly evaluate coeffects until they land in a mainstream language with production usage. What I do know from experience is that you can't quietly block the entire thread on a network request in some innocuous looking function in JS. You have to return a promise and then the calling function has the option to await that promise, but I'm sure the academics in their ivory towers have theorized about something better.

[phyrex]

It doesn't quite fit your requirements, but Facebook's PHP variant has an effects system like that which they use: https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...

[throwitaway1123]

This looks pretty cool. One issue I have from just a cursory glance is that the IO capability includes things like `print` and `echo` [1]. If the context system can't differentiate between `console.log` and `fetch`, then it's a little less useful for me.

If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2].

[1] https://docs.hhvm.com/hack/contexts-and-capabilities/availab...

[2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...

[phyrex]

Hack is custom made for facebook and its use cases, and there’s no use for distinguishing those kind of IO at Facebook. The main use case for the effects system is actually privacy, wherein where processes that aren’t privacy controlled cannot access user data or data that got processed by other functions that did. And that’s enforced by the runtime. It’s super cool and a great example of what those systems are capable of.