[YorkshireSeason]

The purpose of effect handlers, direct-style effects etc, is to let the type-checker/type-inferencer do most of the reasoning about side-effects.

Using such techniques requires an upfront investment of learning how this works, but once that mountain is climbed, programming becomes easier, faster and less error prone in many cases.

[gsliepen]

I agree with it becoming less error prone and more composable. But faster and easier? The examples I've seen in this and other articles about effect systems use many more lines of code just to print a single line than you would use in a language like Python, and that's excluding the definition of the effect types themselves. Ideally, I'd like to get all the benefits of an effect system, but without the verboseness that seems to come with it.

[YorkshireSeason]

Clearly, effect systems, as we know them today, are very heavyweight, and not worth the effort in the small. That's not controversial. But we have to present the ideas to beginners somehow. Those complex types come into their own in (some) large-scale programs, and especially as large-scale programs evolve, as they are being changed by programmers other than the original authors. (Not all programming tasks may be suitable, see the article on Rust for games programming that's on the front page RN.) All that said, the whole point of the article, and the research on direct style effects is to make effect typing much more lightweight. Effect types as we do them today metastasise along the call graph, and that is a big problem (this is also why Java-style exception specifications are considered a mistake). Direct-style effects essentially use implicit arguments, as popularised by Haskell and Scala, to hide much of this complexity. Whether this experiment will succeed, or direct style effects suffer from other problems is unclear and we have to wait until we have enough experience with them. And that can only start, once there is a language that implements support for first class direct style effects.

The article suggests that this is coming to Scala, and I'm looking forward to being a guinea pig.

[naasking]

> The examples I've seen in this and other articles about effect systems use many more lines of code just to print a single line than you would use in a language like Python

This seems to me a bit like complaining that defining C functions and for-loops are so much more verbose than just using JMP instructions in assembly language, so why go to all the trouble of bothering with functions?

The point is that effects and effect handlers are a new form of structured programming, but for effects instead of values. New structure seems heavyweight for trivial things, but ultimately scales and composes better for realistic programs.