[kinofcain]

Are the first two examples equivalent? In the go version, an anonymous function is being declared and then called with the value of the outer 'i'. In the clojure version, it appears that the value of 'i' is part of the closure for that function.

The go version does what it does to avoid a race condition, because the goroutines are being spun up in the background and it's highly likely that it will take longer to spin up at least one of them than it will to finish the loop, so without it you'd likely get output of all nines.

If the clojure version doesn't have that problem, then I think it's a somewhat telling indication of how it's actually working.

TL/DR: The Go version has to work around the race condition because the runtime is doing things "right", is core.async?

[Tuna-Fish]

It's a difference of the language. In the Go version, i is a mutable variable that can be read and written to. In Clojure, it's an immutable bound value. The i of one iteration is not in any way directly linked to the i of another iteration.

[frou_dh]

"The Value of Values"

[hueyp]

The i is scoped differently in clojure than in golang so it doesn't have the same potential pitfall. I think golang people consider their scoping here a mistake (and have tooling to check it?).

[frou_dh]

C# had the exact same pitfall and it was recognised years ago. It's unfortunate that it made it in to Go.

[shakesbeard]

Did they introduce a language solution for it in C#?

[jared314]

C# 5.0 is changing the behavior of the loop variable to be logically inside the loop [0].

[0] https://news.ycombinator.com/item?id=3477629

[pcwalton]

The Go race detector will generally catch this mistake at runtime.

[VMG]

Also see Javascript's IIFE: http://en.wikipedia.org/wiki/Immediately-invoked_function_ex...