Go is still not good

Summary

Previous posts Why Go is not my favourite language and Go programs are not portable have me critiquing Go for over a decade. These things about Go are bugging me more and more. Mostly because they’re so unnecessary. The world knew better, and yet Go was created the way it was. For readers of previous posts you’ll find some things repeated here. Sorry about that. Error variable scope is forced to be wrong Here’s an example of the language forcing you to do the wrong thing. It’s very helpful for the reader of code (and code is read more often than it’s written), to minimize the scope of a variable. If by mere syntax you can tell the reader that a variable is just used in these two lines, then that’s a good thing. Example: if err := foo(); err != nil { return err } (enough has been said about this verbose repeated boilerplate that I don’t have to. I also don’t particularly care) So that’s fine. The reader knows err is here and only here. But then you encounter this: bar, err := foo() if err != nil { return err } if err = foo2(); err != nil { return err } [… a lot of code below …] Wait, what? Why is err reused for foo2()? Is there’s something subtle I’m not seeing? Even if we change that to :=, we’re left to wonder why err is in scope for (potentially) the rest of the function. Why? Is it read later? Especially when looking for bugs, an experienced coder will see these things and slow down, because here be dragons. Ok, now I’ve wasted a couple of seconds on the red herring of reusing err for foo2(). Is a bug perhaps that the function ends with this? // Return foo99() error. (oops, that's not what we're doing) foo99() return err // This is `err` from way up there in the foo() call. Why does the scope of err extend way beyond where it’s relevant? The code would have been so much easier to read if only err’s scope had been smaller. But that’s not syntactically possible in Go. This was not thought through. Deciding on this was not thinking, it was typing. Two types of nil L...