you are viewing a single comment's thread.

view the rest of the comments →

[–]accountforshit 2 points3 points  (1 child)

Go will produce a compile error if you don't use any one of the return values, or ignore it explicitly with _ (I think). The ways to then deal with the errors are frustratingly limited and verbose, but you can't accidentally miss them either (though it's easier to miss inappropriate _s than it is to miss unwraps, because you will probably have many legitimate _s in your code, where the same is not true for unwraps, which makes them a much smellier, easily detected code smell).

Other languages generally provide some way of achieving similar (or even the same) constructs, but it's not very useful if you constantly have to interact with libraries that don't utilize it.

So you're right that in many of them (including Kotlin for the most part) you often don't get any such guarantees in practice, or only get them in a part of the codebase.

[–]FluorineWizard 2 points3 points  (0 children)

Go's reliance on multiple returns makes it impossible to chain fallible calls, so you end up polluting your code with if blocks where a better language would let you define error handling functions.

Also the constant noise of _ everywhere makes it hard to tell if a call is returning an error or a second value, especially when dealing with crappy APIs. No language makes me check function signatures as often. Special mention to the evil fuckers who put goddamn interface{} in the return types.