Frustrations with Go
After a couple of years programming in Go the honeymoon is definitely over. I have thousands of lines of Go code sitting on Github now and I don't think I will be abandoning it, but it's time for a little rant.
There is a lot to like about Go - above all its simplicity. But this simplicity comes at a cost; some apparently uncomplicated things have been omitted from the language and these tend to increase significantly the SLOC of Go programs and packages.
type someT struct {
const maxThings = 20
...
}
...more lines of code required.
var x, y = 1, 2 and x, y := 1, 2 and x, y = twovalfunc()
why can't I write this?
x, y += twovalfunc()
...more lines of code required.
...often many more lines of code required.
... more lines of code required.
I am nobody, so I don't mind being shot down on a mailing list or Slack channel; but when I see highly-respected, venerable members of the programming community repeatedly being given similar treatment it worries me. I don't need my compiler writers to be nice people, but I do want them to respect other people's points of view.
There is a lot to like about Go - above all its simplicity. But this simplicity comes at a cost; some apparently uncomplicated things have been omitted from the language and these tend to increase significantly the SLOC of Go programs and packages.
Missing Features
Enumerations
Although these can superficially be simulated with constants, doing so does not give you the safety of having the compiler warn you when you omit a case in a switch statement. It seems to me that this is precisely the kind of programming error that the Go authors claimed to want to eliminate with the language.Consts in Structs
Time and again I have found myself wanting to write something liketype someT struct {
const maxThings = 20
...
}
...more lines of code required.
Multiple-Value Operators
If I can writevar x, y = 1, 2 and x, y := 1, 2 and x, y = twovalfunc()
why can't I write this?
x, y += twovalfunc()
...more lines of code required.
Stopping Goroutines
A lot of my code deals with hardware or third-party packages I can't change. Sometimes my Goroutines wait on events other than channel reads. Really, life would be a lot simpler if I could stop a Goroutine externally....often many more lines of code required.
Error Handling
What? It has only slowly dawned on me that Go lacks error handling completely. All there is in the standard packages is a convention of treating a returned value as an error. This would be all well and good if you could choose to totally ignore the error value - but you can't, at the very least you have to explicitly swallow it with _. The upshot of this is that it is frequently impossible to write function calls with function calls as parameters.... more lines of code required.
Attitude
This is a difficult one. The Go team apparently prides itself on having an opinionated language. I like a lot of the consequences of this (especially 'go format'), but some members of the online Go 'community' seem to regard this opinionation as a blanket excuse for rudeness and the offhand dismissal of other's opinions.I am nobody, so I don't mind being shot down on a mailing list or Slack channel; but when I see highly-respected, venerable members of the programming community repeatedly being given similar treatment it worries me. I don't need my compiler writers to be nice people, but I do want them to respect other people's points of view.
Comments
Post a Comment