I'm not sure if yet another person comparing their set of agreement/disagreement is useful, but here goes, because I like Go and think some people are skeptical about it with a bit too much enthusiasm because it either seems too hip (this or that well known company or that adopting the stuff) or not-hip-enough (the research-PL inclined and even those who absolutely must have parametric data types).

Agreements:

All of the thumbs-up opinions I share, with the emphasis on that Go fills a niche that is otherwise a relative vacuum as-is.

The Damnable Use requirement, for precisely the reason he states. Add having to constantly frob a binding from "anySymbol" to "_" while doing some instrumentation or whatever. This kind of trivia should be fixable by a program, and otherwise let it remain a warning. I think the occassional positioning of this inconvenience as a feature is unconvincing.

Annoyance at the lack of assertions. I think the concern given by the Go FAQ can be met even without making everyone roll their own assertion construct, but now we have either fewer assertions or a less idiomatic way of identifying them. I think an assertion is quite distinct from an error in that it should indicate a logically impossible condition rather than an unusual one, and I often see this guideline applied in the world at large. As such, I feel the FAQ seems flimsy in its justification, and now I have panics littered about that have a convention indicating their special nature.

Assertions are also one of the very few pieces of software engineering practice that have even a smidgen of empirical evidence in their support as well: http://research.microsoft.com/apps/pubs/default.aspx?id=7029...

Leakiness of semicolon insertion. The abstractions are leaky, but I like not having to type my semicolons and it's not a common mistake I make. Minor.

Lack of clarity with regard to unicode. Yes, the language supports it quite well (as he mentions, unsurprising given its pedigree), but I'd say the type system and operators available only seem so-so, and it seems like more so than with Java or Python3 leaky abstractions between bytes and encoded text are present. Among my favorites:

http://golang.org/src/pkg/text/scanner/scanner.go#L521

Wherein the "rune" returned by the "text/scanner" "Scan()" is used to identify the type of token rather than its value. Sometimes. I was mystified by the type signature for a while (why is this returning a rune, and not a lexeme or lex type?) and had to read the package to convince myself that was the intent. Plus side: this kind of abstraction leakage (or at least free-wheeling coercion) can probably yield much faster code.

Disagreements:

"Violation space in time", whereby the semantics of a statement can be varied by the arity of the binding. I think this is good, and not bad. It's only a little weird that it's only available (afaik) as a special service to channel binding rather than any operator defined by a user.

Buffered Channels and Deadlocks: non-deterministic deadlocks are a pain, and I don't think Go provides any real treatment (or exacerbation) of this problem, however, it probably could make that possible by adding some operators to enable writing a run-time deadlock detector, which can be useful for some programs.

Notable omissions, speaking in the postive:

I think go fmt is great. I don't like everything about the formatting, but I like the slavery-is-freedom approach there.

The gdb support is surprisingly good and neatly integrated into most new gdbs one gets off the shelf. Massive thanks to Ian Lance Taylor.