[frou_dh]

Go's thing is more "encourage" to handle errors than "force", given that the compiler has nothing to say about unhandled errors in the presence of certain variable reuse patterns, or completely unassigned returns.

https://play.golang.org/p/mu5fbUrV322

[dgellow]

That’s the correct way to present it IMHO. With Go you’re encouraged to deal with the error directly (two choices: return it, or do something about it), so that when reading you can follow what is happening at any time. When reading a Go function you can always say for sure if an error occurs with a given call and how it is handled.

If for some reasons the project consider that checking errors should be enforced, that’s simple to do by using go-lint or other linters.

[marcus_holmes]

true, good point. And having the power to ignore the convention is good, too.

[masklinn]

> And having the power to ignore the convention is good, too.

Mistakenly not handling errors is not "the power to ignore the convention", it's "the language is half assed".

"The power to ignore conventions" is being allowed but having to explicitly ignore the error, aka that the second and third cases trigger errors, and that you'd have to write:

y, _ := fmt.Println("Bar") println(y)

_, _ = fmt.Println("Qux")

(also note how you can not use `:=` in the second case, because that requires that there be at least one new variable on the LHS)

[marcus_holmes]

The language allows you to ignore the convention.

There is a plethora of tools available to allow you to detect if you did that when you didn't mean to. It's just that the compiler doesn't enforce it.

[pjmlp]

Given that Go also supports binary packages, those tools won't help much there.