[luriel]

> 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.)

Passing a closure on a channel is both idiomatic and relatively common in Go code.

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).

Edit: His (IMHO somewhat strange) complaint that "Channel reads violate the laws of time and space by changing their behavior based on how their return values get used." doesn't apply anymore, now to do async reads from a channel you use select with a default, not the comma-ok idiom.

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.

[tptacek]

The space & time thing is a joke. Because we're nerds, we have trouble with clashes between literalism and humor. He is saying, the behavior of a function depending on its return value is like the past (the execution of the function) depending on the future (the storage of the result of the execution of the function).

He's a very smart guy (and the author of one of my all-time favorite Mac apps, Hexfiend) and I'm pretty sure he understands what is actually happening.

I'm not sure that spending a lot of time in Go is going to get him over the "Damnable Use Requirement". It is really, really annoying.

[gecko]

You can't send closures over channels in Go.

[crawshaw]

You can:

  func main() {
  	x := 4
  	f := func() { fmt.Println(x) }
  	ch := make(chan func(), 1)
  	ch <- f
  	f2 := <-ch
  	f2()
	x = 5
	f2()
  }

http://play.golang.org/p/NK5YLVT4zB

[ithkuil]

  test := make(chan func (int) int)

  go func() {
    f := <- test 
    fmt.Printf("%d\n", f(10))
  }()

  test <- func(v int) int {
    return v * v
  }