Go 1.6 is Released

Oh, don't mistake my comment for favorable opinion. I only wrote a few hundred lines of Go in my life. It worked well for the particular problem I was solving, but I'm really more of a C/C++ guy.

The problem with lisps is that you need to know lisp, and relatively few people do. It also requires a different approach to program design. It may or may not be a better approach, but the fact is, that's not what most people are trained for.

In contrast, go is imperative through and through, and its syntax is similar enough to C that people find it easy to adapt to it.

There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alternate languages, but that is a whole different barrel of fish). The TLS stack in golang is finicky but I trust it. And gofmt. No really, the best part of golang is gofmt.

For those benefits you trade off vs the jvm a) abysmal tooling b) extremely primitive concurrency support c) a more primitive type system and d) a much smaller ecosystem.

I very much like golang for 2 classes of problem 1) http/s based microservices and 2) command line programs that are a touch more complex than bash. I would never choose golang for a system that I thought was going to have a high LoC count or had a complex domain to model.

One superficial example: There is only one correct formatting of a particular Go source file, so you never have to debate with someone (or yourself) whether to use newlines here or there, or to place that opening brace on the next line, or to put spaces around your assignment operator in that function call, etc. The toolchain formats it the "correct" way and that's it.

Go has a lot going for it.

That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project:

1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain.

By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do.

I might just have memory problems, I acknowledge. :)

However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design.

An interpreter mode might also be quite valuable, to address this problem and the ones below.

2. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: reason", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it.

3. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem.

4. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent.

5. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages.

6. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads.

Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages.

I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there.

In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.

For me, I like Go's slim profile. Native compilation, aggressive allocation, low memory usage, static compilation.

JVM suffers from slow startup times and tends to eat a lot of RAM, even when the app doesn't technically need it around. It has an object model that spawns a bazillion tiny objects, and much of the JVM's GC design exists to cancel out those tiny object allocations.

JVM has many upsides (the portability and pluggable nature of JAR files is a huge one), but I think a lot of people are attracted to Go's bare-bones approach. Closer to the metal, a "better C", smaller overhead.