This seems like more of an issue with porting an existing language than creating a new one. With the “can write to the file system” example, you would only need one version of a “writeJSON” function, for example, because writing without write access is nonsensical. Then you’d specify exactly what you need through these constraints, and if they weren’t met, you couldn’t call the function. This already exists and works well when it comes to const-correctness in a language like C++. You can’t call a non-const method from a const one, for example, and this doesn’t lead to multiple versions of each function, because if a function mutates state, you know that it will never be able to be called from a const method.

You probably need at least one WriteJSON that's synchronous and one that's asynchronous, with different colors. If you want a version that uses memoization internally, it needs the "can allocate memory" color, which is independent of the async/sync color.

Could it be possible to infer optional colors from the environment?

You denote that the color is optional in the function's type signature, and inside the body of the function, you have a construct that lets you execute different code depending on the state of the function's colors. The call site could either automatically infer the colors used or the colors used could be manually specified.

Basically a type parameter with compile-time if statements.

So, algebraic effects?

If js had async/await from the beginning there would have been no need for the callback version. Also the sync apis would exist in any case because of the event based architecture of node and the fact that at times you don't want to release control back to the event loop.

That's not a problem, those are all individually useful when doing systems programming. Sometimes you're implementing a thread worker and you want (1). Sometimes you want to plug in existing functions and you want (2). Sometimes you want to use I/O completions so you want (3).

It makes sense to avoid this in a javascript runtime because you actually almost always want (3) there. It's too late for node to change it unfortunately. But I'm also pretty confused as to why zig, a (relatively) low level language, considers it important to remove this distinction.