Go Bloviations

&#62; This seems like needless boilerplate: why not instead simply pass a closure over a channel that the goroutine will execute? I have never seen this technique used in Go, but it seems natural to me. (It's essentially how libdispatch works.)<p>Passing a closure on a channel is both idiomatic and relatively common in Go code.<p>This and other comments make me suspect the author could have benefited from spending more time looking at existing Go codebases (the source of the Go stdlib is excellent).<p>Edit: His (IMHO somewhat strange) complaint that <i>"Channel reads violate the laws of time and space by changing their behavior based on how their return values get used."</i> doesn't apply anymore, now to do async reads from a channel you use select with a default, not the comma-ok idiom.<p>Also a package including more 'clever' Unicode operations will also be part of Go 1.1, but I have personally never found the existing support lacking, and no, I don't live in an English speaking country.

A couple of responses:<p>- I too dislike the lack of a ternary operator. Python has this problem too (you can create boolean expressions to sorta mimic it but it doesn't tend to be considered "Pythonic"). And brevity is my reason too. I'm sure it's easier to parse without it but it can't be that hard.<p>- On the "damnable use requirement", I see his point. If anything, it means that Go will be better used with IDEs than text editors that'll do this for you automatically;<p>- On the "thread safe set", yeah he's Doing It Wrong [tm] (which I think he knows). You use channels to share state in Go rather than creating shared state directly.<p>- Unbuffered channels seem to be idomatic. Race conditions and deadlocks seem to often be the result of using buffered channels;<p>- On his channel reads issue ("violating time and space") I disagree: it's good to have blocking and non-blocking channel reads.<p>I basically agree with his conclusions, particularly in Go feeling like a "modern C", something I desperately hope succeeds.

A couple of remarks. FWIW my job is as a Go programmer.<p>The unused variable thing (particularly with local variables) has caught many bugs quickly for me. If there's a package that I find myself always adding and removing, it's easy to write a function that freezes it. For instance, for the debugging print example:<p><pre><code> func printf(f string, args ...interface{}) { log.Printf(f, args...) } </code></pre> (I tend to use log for debugging prints rather than fmt, because it's guaranteed thread-safe, and it's easier to separate debugging prints from necessary prints at a later stage).<p>On the few occasions that I've really felt I lacked a ternary operator, I've just coded one up for the occasion:<p><pre><code> func either(cond bool, a, b string) string { if cond { return a } return b } </code></pre> No big deal. I do find myself writing little functions as building blocks quite a lot, but I think this works well. Functions are a great building block, and Go is great for assembling blocks.

I've started using the builtin "println" function for stdout debugging to get around the Damnable Use Requirement. It works without any packages imported, so that the very low-level stuff can tell it's alive without a full stdio library stack in place.

&#62;I used Google's new Go language for two days.<p>I don't mean to be rude but, please don't write about about things you've only used for two days. This is a massive problem for all new things. Initial impressions mean a lot, and you honestly can't grok a new language in 2 days to effectively blog about it. If everyone here tried to go out and criticize Haskell after two days of usage, I don't even think they'd understand enough to criticize it beyond "it's too complex".<p>Lots of the decisions made for the Go language aren't for the hobbyist. It's targeting building large, powerful, heavily code-reviewed systems because C++ with an enforced style guide is a nuisance. Let's look at an example decision: the "use requirement" is actually godsend for removing unused dependencies. Go compiles as fast as it does partially because of its powerful dependency resolution. Rob Pike has a story about an engineer accidentally compiling a library 80,000 times in the same C++ build without knowing for years. The author of this blog got mad because it was inconvenient to debug with print. Now if only he hadn't been using the language for two days, he'd know that the Go compilers don't have to, but implement a builtin called print and println specifically for debugging. You don't need to import fmt to debug with print/println.

<p><pre><code> sm &#60;- commandData{action: length, result: reply} return (&#60;-reply).(int) </code></pre> wowza.

his SafeSet implementation exposes functionality as exported fields instead of exported methods. That should be a red flag to anybody with any real-world Go experience. Exposing functionality through channel fields obviates the possibility of generalizing the functionality as an interface. It also creates subtle traps, where the caller must now know whether they're expected to set these channels to be buffered or unbuffered.<p>If you're dead-set on implementing this with channels, those channels should be unexported and hidden:<p><a href="http://play.golang.org/p/zRSco7MpMl" rel="nofollow">http://play.golang.org/p/zRSco7MpMl</a><p>In reality, it's far more sane to just say `type SafeSet struct { d map[string]bool; mu sync.Mutex }`, again exposing all the functionality through methods, and just locking and unlocking the mutex as necessary. If using a mutex makes the implementation more clear and is semantically equivalent, then use a mutex. That's not typically the case, because typically the case involves more than just locking and unlocking. In this particular example, all you need to do is lock some resource, so it's ok to just use a lock.<p>And the claim that there's no data privacy isn't correct, it just assumes a data privacy model that Go doesn't have, namesly the "public" and "private" notions. Go instead opts for the notion of "exported" and "unexported" fields and methods; i.e., fields and methods that may be used only by code within the same package. It's a different mechanism for hiding data, but it does exist.<p>Anywho, if you want to see a completely absurd, lock-free (not strictly nonblocking), threadsafe queue in 51 lines of Go using higher order channels, just for kicks, see here: <a href="https://gist.github.com/3668150" rel="nofollow">https://gist.github.com/3668150</a>

Instead of<p><pre><code> if expr { n = trueVal } else { n = falseVal } </code></pre> Just do<p><pre><code> n = expr !</code></pre>

There's a pattern you should be using here, instead:<p>"""<p>Something doesn't work right, so you add a call to fmt.Printf to help debug it. Compile error: "Undefined: fmt." You add an import "fmt" at the top. It works, and you debug the problem. Remove the now annoying log. Compile error: "imported and not used: fmt." Remove the "fmt" knowing full well you're just going to be adding it back again in a few minutes.<p>"""

i believe he'd be happier with D, which addresses a lot of the issues he had with go, and which can genuinely be used as a better C++.

It's very hard to do Test Driven Development in Go because there is no mocking library that can help with stubbing constructor or static method.<p>I feel that people who jumped ship from dynamic language such as Ruby or Python to Go have no idea what they are giving up. Maybe they never practiced TDD to begin with.<p>Heck, even Java is more friendly with TDD by using Powermock or JMockit library.

&#62; <i>For small compiles, the Go compiler was blazingly fast; on a large synthetic codebase (700 files), it was three times slower than clang compiling C.</i><p>This really stood out for me and seems to make a mockery of Go compile times for larger programs and perhaps more real-world situations.

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).<p>Agreements:<p>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.<p>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.<p>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.<p>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: <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=70290" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=7029...</a><p>Leakiness of semicolon insertion. The abstractions <i>are</i> leaky, but I like not having to type my semicolons and it's not a common mistake I make. Minor.<p>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:<p><a href="http://golang.org/src/pkg/text/scanner/scanner.go#L521" rel="nofollow">http://golang.org/src/pkg/text/scanner/scanner.go#L521</a><p>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.<p>Disagreements:<p>"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.<p>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.<p>Notable omissions, speaking in the postive:<p>I think go fmt is great. I don't like everything about the formatting, but I like the slavery-is-freedom approach there.<p>The gdb support is surprisingly good and neatly integrated into most new gdbs one gets off the shelf. Massive thanks to Ian Lance Taylor.

If you have control flow that increases cyclomatic complexity it should be visible (explicit if), not hidden in an expression (ternary operator).

The Use requirement is related to Go's refusal to have compiler warnings. It is a well-intentioned step in the wrong direction, overtaking even Bondage and Discipline languages. Haskell's GHC just addded a flag to make type errors warnings!<p>The closures capturing references thing is a big design bug. If a programmer wants a to share a reference, he has the &#38; operator.

By the way, it's not true that Golang strings are always UTF-8. Golang <i>source code</i> is always UTF-8, but strings can contain arbitrary bytes. Trying to force all strings to be UTF-8 can lead to fiascos in the real world, where legacy encodings still do exist. (Although you SHOULD NOT add to the problem by creating new systems that use them!)<p><a href="http://golang.org/pkg/unicode/" rel="nofollow">http://golang.org/pkg/unicode/</a> lists a bug at the bottom: "There is no mechanism for full case folding, that is, for characters that involve multiple runes in the input or output." So basically, they are aware of the bug / lack of feature and are working on it.