[LudwigNagasena]

I think it is a cool feature, but I see some practical issues.

For me, encapsulation is a feature. I would like to see that a function uses a network call deep down, but only in a static analysis sort of way. So I don't want to mark something as potentially using a network until it actually uses it. And at the same time I wouldn't want to change every effect of every intermediate function just because I made something use an LLM or Redis cache.

It also seems that cross-cutting components such as observability instruments are just going to contaminate all functions with their need for memory, network, io, files, clock, locale, reflection, etc.

[kephasp]

First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic.

But I see the need to change the code as a good thing when it is necessary: I don't want a dependency, inside or outside my codebase, to suddenly add network calls without me knowing it. Same goes for code that was pure and has become stateful. Not knowing this kind of fundamental change is a recipe for a nightmare.

It should be especially apparent with the recent supply chain attacks.

[LudwigNagasena]

In the real world you usually want to extend datatypes and provide new implementations without recompiling let alone rewriting old code (The so called expression problem). This is the raison d'être of complex DI and IoC enterprise patterns and various monkey patching techniques.

I am not sure how flexible the effect approach is. It took decades before static typing became painless enough for rapid agile development. Properly typed DI with safeguards sounds wonderful, but can algebraic effects actually deliver that?