The language.
At work, recently, I was tasked with experimenting with go (the language), to get at least a vague idea much work it would be to build a go API for some software we produce. This post is somewhat in the nature of a review of the langauge. (In general, not as it relates to work's particular purposes.)
First is that the language mandates way too much style. The semicolon insertion rules dictate quite a lot about code formatting; this starts with brace placement, but continues to, for example, forbidding ending a line with a close paren that closes a subexpression but not the whole expression.
Second is that, as far as I can tell, only one implementation exists. I am very uneasy with any language that doesn't have multiple independent implementations. When that implementation comes from an organization that makes a business of invading everyone's privacy I am especially leery. (It doesn't help that the implementation is written in go, leading directly to a Reflections On Trusting Trust moment.)
Third is that it can't seem to make up its mind whether strings are character strings or octet strings. It seems to try to do both and, not surprisingly, ends up with something like the worst of each. And it mandates that source is written in UTF-8; even at the source-code level it exhibits confusion between octet sequences and character sequences. This will cause it pain once the world moves beyond 8-bit addressing units.
Fourth is a strange blind spot. For work, I was trying to wrap a C API in go wrappers, mostly using cgo. At one point the go code had a C pointer-to-char; it wanted to print the pointed-to chars, until the first NUL or until 40 chars had been printed, whichever came first. In C, this would be nothing more than using `%.40s' with printf. In go, I have yet to find a way to do it, short of handling each char separately. go's fmt.Printf requires a go string, not a C string, and, while I could get the length I wanted by calling C.strnlen, I found no way, short of handling each octet separately, to convert that into a go string with the same contents, without risking accessing bytes beyond the length when that length was under 40. And I can't call C.printf because cgo simply doesn't work with stdarg functions. I finally thought I had a way using the reflect package, only to find that the documentation for reflect (which exists only on the web, making it impossible to tell whether it's for the version I have installed, not to mention being useless when disconnected from the net) documents an ArrayOf call which simply does not exist in the reflect package I have.
I feel as though I should be calling this language `stop' instead.
The game.
I've been playing go roughly weekly for the last, what, year or two. There's a game cafe I've been going to where I taught someone to play. He's been playing online and is now significantly better than I am; he routinely gives me 3-5 stones and not infrequently wins anyway.
Historically, I've thought of myself as being somewhere around 15 kyu. But, at Anime North last year, I played someone substantially better than I; we played a partial game even-up, then, when it became obvious he was much better than I, we restarted with, IIRC, 5 stones. We had to abandon the game because of time (he was winning; I kept overextending myself), but he did estimate I was probably around 11 kyu. With the practice since then, I may be slightly better now; I might have made it into the single-digit kyu ranks.
And one of the staff at the aforementioned game cafe has expressed interest in learning. I like this; I don't see any downside to getting more people playing go.