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