Sorry for the confusion.
In this article, I’d explain what I thought about Go without mentioning “dream” (because it will confuse others), “pragmatic” (because most language is designed to be pragmatic) and “industrial” (because I’m not Martin Odersky).
As a language, Go is small. There is no generics, no operator overloading, no Maybe or Option. However Go has operators (unlike Lisp) and Go’s “append” can treat []int and []string in a type safe way because lex.c and typecheck.c know “append”.
There is a gap between language designers and language users. There is a valid use case to define operators and generic functions. And the designers can use them but the users can’t (or compared to the cons it introduces in the language, it doesn’t seem a valid use case from the designers).
Having such a gap makes Go different from C++ and Scala. These languages have a lot of features and it allows users to behave like designers. Since integers and std::string can be concatenated by “+”, your classes can be concatenated by “+”. STL containers are type safe and you can build your type safe containers over same building blocks STL uses. Moreover Scala allows users to define new operators and actually Scalaz defines them with Unicode characters. And of course, Scala has macros!
Then you can show your awesomeness by defining things like designers. The languages don’t treat yours like a second-class citizen. How dreamy! But well… you are not so awesome in fact. Your dream might be a nightmare for others.
Let me recap without mentioning “dream”. Maybe what I miss is extensibility. Go is simple but as a result of simplification, it enforces us to define rational numbers like math.big.Rat. Go’s map is implemented as a hash map. If you need to have a tree map instead, you have to define a type specific container like IntTreeMap. You can implement Rope, but you can’t treat it like Go’s strings.
It’s not a big deal maybe and I would use Go in somewhere. I’m just missing what I had before.