Biggest problem with Go:

Googling for it!! "Go" is everywhere. "Google go", golang, go-nuts and golang-nuts tend to coincide with the language but it's really hard to find resources easily. I've learned to just go to the golang-nuts group and search there.. but what about when the userbase grows beyond a single community?

The language is awesome though, elegant both in design and implementation.

Out of curiosity, what resources were you not finding? The language itself and the standard libraries are pretty well documented on golang.org, and searching for "golang <keyword>" has always worked quite well for me to find any third party library I happen to be looking for.

I'm working on a wrapper for BLAS (basic linear algebra subprograms) that will hopefully be able to interoperate between CBLAS and CUBLAS (nvidia's GPU implementation) by the time it's done.

BLAS has fortran/C heritage so it expects matrixes to be a single contiguous chunk of memory, indexed by column first and then row. Whereas a go [][]float64 is a pointer to an array of slices, which are pointers to noncontiguous arrays. Additionally, the CUDA API has a "special" malloc function that does some bookkeeping and gets big performance gains. So, trying to figure all of that out, plus this is my first go project (great first project, huh), so basically every other newbie question I've had.

Basically obscure enough questions were better to search golang-nuts directly.

i've definetly had the same problem googleing for go resources. i also eventually figured out that doing a search for golang <whatever> was the best way to go.

still it can be kind of frustrating for a beginner with the language to always get the query wrong the first time. luckily the documentation and source code available on golang.org is really useful.

Same problem with IntelliJ IDEA. "IDEA" must be the worst product name ever for googling.

Any go enthusiasts mind explaining this one? It looks like a very strange syntax:

  No, Andrew described this case:
  
  > should be rewritten as,
  
  >        select {
  >        case ch <- v:
  >                // sent
  >        default:
  >                // not sent
  >        }
  
  Without the default, the select statement becomes blocking.

See http://golang.org/doc/go_spec.html#Select_statements for the relevant documentation. What select does is selects which communication option to do, and it blocks until one of the options is available. So if you select on one option, you will block until you do that. But default is always available, so now you don't block.

Nobody really uses the non-blocking channel receive operations. I didn't even know it existed until now.

Selecting on multiple channels is, however, is used very often, so this fits that paradigm quite well.

What does it actually do? Executes the body of the case for the channel which has output?

Yes, that's right, and only once. It's like a switch statement, only using inputs instead of fixed cases.

It does make sense to have the blocking version, if there's nothing else to do.

There is also a fairness point: If more than one channel is available, which one to go is selected in a fair way. This is important so a channel at the top can not flood and monopolize the selective communication primitive.