As a no-go programmer looking through the data race detector docs (http://golang.org/doc/articles/race_detector.html), it to me shows snippets of a really ugly language with poor readability. Examples from Google's page:

  var service map[string]net.Addr

When I read this it's easy to skip seeing string, aside from the fact that ] as a delimiter also looks like net.Addr was accidentally combined with the previous line.

  func ParallelWrite(data []byte) chan error {
	res := make(chan error, 2)
	f1, err := os.Create("file1")
	if err != nil {
		res <- err
	} else {

Here we see no parenthesizes used in if statements, yet we retain {. In skimming it's easy to miss the if in the first place. Yet everywhere else they're happy to use parenthesizes. We also see that "make" is lowercase yet a method, but os.Create and ParallelWrite has caps for a method.

There's also the fact that the array (I'm guessing) of bytes diverges from every other language to put them in front of the type which looks like crap. We see the same poor choices of delimiters as with map value types.

Then there's this

  func main() {
	c := make(chan bool)
	m := make(map[string]string)
	go func() {
		m["1"] = "a" // First conflicting access.
		c <- true
	}()
	m["2"] = "b" // Second conflicting access.
	<-c
	for k, v := range m {
		fmt.Println(k, v)
	}
  }

<-c looks like its just dangling, and if this is meant to say there's some kind of stream or assignment then does it just go to /dev/null? Yet "c <- true" is also correct? I'd argue for either void <- c, _ <- c, or c.read() if wanted to support something like that.

It's also difficult to tell in the for loop if v is being assigned as "range m", or if "k, v" are a tuple resulting from "range m"

It's too bad because the goals of the language are quite nice from a CS perspective.