Stefan Schimanski

not sure this is Go's fault ... replace nil by None and you got some Python :)

Many other languages would have a sum type to express the intent better: Either[GiantTuple,Error]

Sure, Rust and Haskell do this very nicely. But you can still abuse those languages and writing non idiomatic code. That doesn't say much about a language.

No question about that. And actually the real point of critic is the repeated error handling if clause. Not the many nils. The later become awkward due to the former.

for _, applyer := range [] interface {Apply to(...)}{ Thing, thing, thing } { if err := applyer(config) ....

Nope, ApplyTo signatures (can) differ.

Exactly none in your image do

time to convert the return value to a struct? ;-)

With 80 columns as the limit we can still add some more nils :D

reminds me the publisher bot scripts input arguments :-) we can always add one more.

Induction: if you can have n arguments, you can have n+1.

This is horrible. Is that how things are done in Go?

No. This is just someone's shitty API design.

Nope, it's no API. internal plumbing code.

I was referring to the API / interface of that particular function. Having 7 return values is a real bad code smell in any language.

Agree.

I don't get your point. If you agree on «having 7 return values in a function is a code smell case» Why are you ranting about that code in Go?

I never ranted. I observed what happens with code that is iteratively extended by many authors following the pre-existing code pattern. The result smells, but it‘s superficially ugly only. It‘s super uniform. Uniformity is beauty. What is more important?

Most probably y misunderstood your initial tweet, because I thought that saying «today in go», you meant «it only happens in go» But yes, you're right. When people adding more and more functionalities don't take their time to think, it happens situations like the one you showed.