[mopsy]

I don't think it's because of the complexity. I'm quite sure it would not have been difficult to do.

One of the reason is that you don't always want to check the error. The most common one is fmt.Println.

I would not like to always write

_, _ = fmt.Println("Hello, playground")

[stubish]

You certainly do not always want to write _,_ = fmt.Println("Hello, playground"), and I think this points out the real lack. What do you want your program to do if fmt.Println starts failing? I think, unless you are explicitly checking for errors, that in all other cases you want it to crash. Rather than silently continue. Which is a bug, and a potentially disastrous one, that is endemic in Go code (and, to be fair, plenty of other languages). Thankfully the practical risk of this particular case is tiny.

This is why you want unchecked errors to implicitly bubble up. Which is what exceptions give you, or perhaps a syntax with implicit error return values rather than Go's by-convention approach.

[pstuart]

If fmt.Println fails you've likely got bigger problems and the game is over.

And if it means a lot in this case, wrap the function and use it instead.