Some Go Irks and Quirks

Now that Jump Start MySQL is published, I’m taking advantage of the spare time I have on my hands while it lasts. I’ve helped organize the Syracuse PHP Users Group, reconnected with some old friends, and gave some love to Kiwi, my forever-project programming language. Moreover, I decided to rewrite Kiwi using Go as it’s one of those languages I found interesting but never had a reason to use in any serious fashion. And now that I’ve got some real experience with it, while I still find myself impressed by some of Go’s features, some things have become really annoying.

I still really like Go’s data typing; it’s static, but it feels dynamic because the compiler is smart enough to deduce a value’s type. If you write your code well then you’ll rarely see a type name outside of a function signature or struct or interface definition. It’s nice to have type safety without the verbosity (yes I’m looking at you, PHP7).

I wish := behaved slightly different, though. Instead of always an allocation, it’d be nice if it could also perform basic assignments. Then we could write code like this:

foo, bar := baz()
foo.x, fizz := quux()

But as it is now, the best we can do is:

foo, bar := baz()
var fizz MyType
foo.x, fizz = quux()

If there’s a go-ism that works around this that you know of, feel free to let me know.

The dangling comma in a list, but only when its closing brace is on a new line, is also irritating. No, it’s not a formatting issue; gofmt won’t enforce one brace placement over the other. Rather, the presence or lack of a comma is a parsing error. We can write:

{foo,
bar,
baz}

And we can write:

{foo,
bar,
baz,
}

But we can’t write:

{foo,
bar,
baz
}

Perhaps it was because I was writing my own parser at the time that this bothered me. It should be trivial to accommodate the desired pattern, especially since structs and interface definitions are brace-delimited and don’t use commas at all.

Go elides some traditional constructs, for example for handles for, foreach, and while loops, so why make and new still exist side-by-side, even when Rob Pike proposed merging them, leaves me scratching my head. &Foo{} is equivalent to new(Foo), so if there’s no need for while then there’s no need for new.

I recognize these gripes are largely syntactic, but the syntax of a language is its API. Programmers are immersed in it every day and it can have an effect on how we think about things.

Surprisingly though, and perhaps this is my biggest complaint, the tooling around Go is still immature. In the 6+ years after its release there is still no killer IDE. Code coverage can only be generated for one package at a time, not and entire project. It’s possible to script coverage for project-wide results but that’s just a hack. Debugging with GDB is brutal and I could not get Delve to work for me.

None of these irks will stop me from using Go in the future if I have the opportunity, but I’d like to suggest Go at work as the go to language (pun intended) for some of the work we do now in C. I can probably make some good technical arguments to sway our old-time C programmers, yet convincing management and the programmers fresh out of college to use Go without viable tooling is going to be a hard sell.