The best summary would be that I want a language to replace C++ but more sane and functional. Go is more like a language to replace Java and is most definitely not functional.
Essentially, I don't see why I would ever use Go over Haskell or OCaml. The main areas where Haskell and OCaml are ill-suited are the lower-level ones currently dominated by C/C++ and Go does not seem to address those very well. The main areas Go is doing well, like server-side code, are very well suited to Haskell and OCaml and so I have no reason to drop down to a less declarative language like Go.
Rust, on the other hand, seems to be targeting C++ directly. It also doesn't hate functional programming. So it perfectly fills the C/C++ shaped void in my current toolbox.
Go is a language for young programmers who were perhaps brought up on Java or Python, but have discovered the "cat -v" mentality and are drawn toward it.
Or alternatively, for old C programmers who are well versed in the 'cat -v' mentality who have tasted a bit of Java and Python but simply cannot buy into those.
Go is a language for those who love the simple C/UNIX approach but would rather have a Garbage Collector there.
I'd like Go to have manual memory management: But Google decided it was better this way.
I don't really see it as a replacement for Java: But maybe for C (In non-critical performance software) or Python.
To most programmers, Go is less scary and foreign than Haskell/OCaml and thus easier to learn. Much as I love Haskell, I'll admit that's a pretty important advantage for Go if you need a team.
Essentially, I don't see why I would ever use Go over Haskell or OCaml. The main areas where Haskell and OCaml are ill-suited are the lower-level ones currently dominated by C/C++ and Go does not seem to address those very well. The main areas Go is doing well, like server-side code, are very well suited to Haskell and OCaml and so I have no reason to drop down to a less declarative language like Go.
Rust, on the other hand, seems to be targeting C++ directly. It also doesn't hate functional programming. So it perfectly fills the C/C++ shaped void in my current toolbox.