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

[gsliepen]

> defining C functions and for-loops are so much more verbose than just using JMP instructions in assembly language

Are you sure? It's not just a JMP; for a loop you need a compare and increment/decrement instruction at the very least, and calling a function is way more complex than a JMP: you have to place the function arguments in the right registers and/or on the right place on the stack, you need to save registers that might get clobbered, and you need to push a return address before you jump. So in C these things are definitely more compact to write.

I did get the point about effects introducing a new form of structure and composability, and I'd really like to see that. But at the moment it looks like it is as much work as actually implementing a function call in assembler, the only benefit is that the compiler will check the correctness for you.