&gt; It&#x27;s much nicer if you can see which methods are the throwey ones immediately - =&#x2F;&lt;- is a real sweet spot in terms of having the difference be visible but not overly intrusive.<p>Well, I guess that&#x27;s a matter of taste, but 1&#x2F; what information does &quot;effectful&quot; convey if you don&#x27;t know what the effect is until you mouse-over? 2&#x2F; I think that&#x27;s a very, very low price (if it is a price at all) to pay for something that fits much better with non-pure languages.<p>&gt; I want to be able to have a value of type IO a outside a method - e.g. in a static field<p>But continuation effects don&#x27;t have `IO a`, just `a`. The effect comes with the context. An `IO a` would translate to a lazy value, namely a function, which could be a continuation. There&#x27;s nothing stopping you from storing a continuation in a field. You can manipulate the `a` just like any value, and the &quot;IO&quot; with handlers -- just as you do with monads.<p>&gt; possibly skip the rest of the computation, returning an Error instead<p>Yes, but  that&#x27;s not all Either says. It says &quot;return an error or a value of type a&quot;. In imperative code that makes less sense. What you want to say is: &quot;throw an exception or don&#x27;t (and return whatever value it is that the function returns)&quot;. The type of the normal return value is not recorded in the Either.<p>&gt; The point is the reason you have to use the horrible monad transformers is that the order in which you evaluate these effects matters<p>You need monad transformers not because of ordering, but because monads don&#x27;t generally compose. Or it&#x27;s a bit reversed: because monads don&#x27;t compose they are sensitive to <i>accidental</i> ordering (whether you care about the order or not), which makes monad transformers tricky. With continuations you have the choice of when to be sensitive to order and when not to.<p>For example, in the imperative case, you <i>could</i> encode the information &quot;if there&#x27;s an early error, are later log statements recorded, or not?&quot; directly in the type, (I think) but I don&#x27;t see any reason to. In Haskell you must because the types need to be nested in one particular way according to the transformer.<p>In any case, my claim is as follows: <i>if</i> you generally prefer the imperative way of doing effects (like in Java, OCaml, F#, Scheme, JS, Python, Clojure, Erlang etc.) -- as I do -- <i>then</i> continuations are far more natural than monads. If you prefer the PFP way, you should stick to monads (or if using Haskell, must stick to monads).