&gt; Well, extremely low-overhead of just about anything is certainly achievable with modern JITs[1].<p>Can&#x27;t read twitter where I am, but to be clear I was primarily thinking of the code-readability overhead.<p>&gt; Why is that necessary? You might as well presuppose the necessity of types :)<p>Well for me the value of using a monad to capture an effect is to be able to verify that I&#x27;ve sequenced that effect correctly at compile time. E.g. I use a monad to represent a database action that has to happen inside a transaction and the type system can enforce that I wrap it in a transaction. In a language without types it would be technically possible to do that, but entirely pointless, because if I get a mistake it&#x27;s a runtime failure on that codepath either way. Maybe that was your point, but while monads are technically possible in dynamic languages, the technique that yields a lot of the value from using monads isn&#x27;t.<p>&gt; or, alternatively, say that you need a type system to verify that your monads are truly monads (i.e. obey the monad laws) at compile time, something Haskell doesn&#x27;t do, either.<p>If I have a given defect rate in the sequencing of some effect, then isolating the fallible heart of that sequencing in a short piece of code is a big win (and I can e.g. flag that critical section for additional review). I do prefer to have a type system which verifies the monad laws at compile time, and I do think that the stronger the enforcement around the monad system, the more worthwhile it becomes to manage a given effect explicitly.