[dullgiulio]

1. Your assumption is wrong, I definitely didn't mean panic.

2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To use them the same way proper error handling is done in Go, you would just have more nesting and multiple unwraps, which is marginally different than Go syntax (but definitely with more compiler checking.) The arrow syntax in Go is used by channels.

[mrkgnao]

Apologies. In any case, monadic errors in Haskell allow you to make "failing early" automatic. Even a simple use of optional types can make a difference. For instance, here you're failing with the same error every time, like here:

    a, err := squareRoot(x)
    if err { handle(err) }    
    b, err := log(a)
    if err { handle(err) }   
    c, err := log(b)
    if err { handle(err) }

you can just use an optional ("Maybe") type: write a, b, and c with types like

    a :: Double -> Maybe Double
    

and then do

    a <- squareRoot x
    b <- log a
    c <- log b

If the computation of a fails, the whole computation fails. The compiler takes care of all the error-checking plumbing. I think the ergonomics of this common kind of situation are really suboptimal in Go, which to my knowledge doesn't support anything remotely similar.

[dullgiulio]

That's right. But I prefer to decorate each error as it comes back from the callee, writing what I was trying to do that failed. This gives a human readable trace of the problem, and also a unique signature for the error itself.

[masklinn]

> But I prefer to decorate each error as it comes back from the callee

That's trivially feasible and still shorter than the Go version:

    a <- decorate (squareRoot x)
    b <- decorate (log a)
    c <- decorate (log b)

Outside of the do context, your return value is just that, a value, you can manipulate it using the language's regular tooling. And you can decorate the do context itself if you want the same decoration for all calls in the block.