My post was tempered, even and acknowledged the shortcomings fairly. Your response indicates that you missed that.

No, my response indicates that I do not think your post was "tempered, even and acknowledged the shortcomings fairly" (and the one I picked is merely the worst, your hello world is as disingenuous as Java's with all newlines removed — a single line)

But hey, I guess I'll give you credit where credit is due: you do know Go's error handling is only an improvement compared to C's, although you still err in declaring it "far better".

Because I did not expound upon the intricacies of error checking with sum types? Responding to inaccuracies about Go does not imply I need to exhaustively describe all alternatives in order to be even-handed. Namely, I was responding to the OP's claim that the Go compiler did not "enforce" error checking. But it certainly does to some extent. I acknowledged that such enforcement was not exhaustive and that errors could be ignored by the user. I even acknowledged insidious cases where the return values are never captured at all.

> (and the one I picked is merely the worst, your hello world is as disingenuous as Java's with all newlines removed — a single line)

I ran `gofmt` on that code before sharing it, so it conforms to Go's "One True Style". More importantly, my "Hello World" is quite readable, unlike a single line Java "Hello World". This last point in particular addresses the OP's central point: that Go is just as verbose as Java because of the length of "Hello World".

> Because I did not expound upon the intricacies of error checking with sum types?

No, it's got nothing to do with sum types, Erlang does not use sum types yet for all the similarity of Go's error handling to Erlang's, Erlang is vastly superior.

> I acknowledged that such enforcement was not exhaustive and that errors could be ignored by the user.

And that's insufficient, errors can almost always be silently ignored by the user (even in languages with sum types which turn errors into faults, you should be able to silence the fault). The issue in Go is that ignoring errors is the simplest thing you can do. And not only that, not ignoring them is a significant step up in complexity and amount of code.

I'd really appreciate if you stopped quoting me out of context. I never said sum types were the only alternative. The second sentence of my GP was "Responding to inaccuracies about Go does not imply I need to exhaustively describe all alternatives in order to be even-handed." I referenced sum types specifically because it is often what people suggest should have been included in the language.

> The issue in Go is that ignoring errors is the simplest thing you can do. And not only that, not ignoring them is a significant step up in complexity and amount of code.

I agree that error handling requires more code, but I disagree that it increases complexity. Most error handling cases I've ever written are just passing them up to the caller:

    if err != nil {
        return nil, err
    }

That is not added complexity IMO---particularly since it is an extraordinarily strong idiom---so I suppose we are at an impasse.

> That is not added complexity IMO---particularly since it is an extraordinarily strong idiom---so I suppose we are at an impasse.

Yes, if 10 tokens, 3 lines and a conditional are not added complexity to you, I suppose we are.

Not in this case, no.