[chrisdotcode]

This:

    images <- get "http://example.com/images.json"

is objectively easier to reason about than:

    var images;
    get("http://example.com/images.json", (err, resp) =>
        if err throw err;
        images = resp;

even though the former might be internally implemented as the latter.

In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up erroring, and you use it again, then it'll short-circuit without crash, very similar to `then()`.

[zak_mc_kracken]

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors.

I can make my code arbitrarily short if it doesn't have to be correct.

[chrisdotcode]

That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).

[zak_mc_kracken]

The same can be said of exceptions.

However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.

[chrisdotcode]

Right - What I'm saying is that the above former code does handle the error, in the exact same way as the latter code.

For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.

[tel]

It's not really the same as exceptions in a typed language because it's forced to be delimited. Even in Javascript you'll have to do a little ceremony to "escape" the golden path driven by the monad, though you'll have many ways to take short-cuts and forget details.