[afdbcreid]

But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".

[throwaway894345]

> But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".

Go typically does get in your way when you're doing things wrong, but yes, I'd like to see Go require return values be dealt with or explicitly ignored. That said, there are linters for this, but in practice it's never been a material problem for me so I haven't bothered to wire one into my project. Over time, I've learned not to be so concerned about issues which are mostly just theoretical--there are enough practical problems to deal with first.

[yencabulator]

> I'd like to see Go require return values be dealt with or explicitly ignored.

Ever use the return value from fmt.Println?

[throwaway894345]

Not usually, but the correct answer would be to either explicitly ignore the unused return values or use APIs that don't return values you don't care about.

[preseinger]

    _ = fmt.Println("ok") // 1
    fmt.Println("ok")     // 2

1 is unambiguously worse than 2.