How do you make a custom, generic data structure without syntax overhead? I have not seen any counter proposal to this aside from "maps should be enough for everybody".
How do you avoid the noise from not having operator overloading or a similar alternative? This, again, goes unadressed.
What are the succint alternatives to functional abstractions for quickly processing collections of data?
"Just use a channel" doesn't really ring like a reasonable alternative to these questions.
In real-world code, the need for generic data structures is shockingly uncommon. It really is. This requirement exaggeration comes about by people acting as language tourists, building amorphous code of uncertain purpose, where things like "I'm going to sum up a bunch of unknown objects" seems like a serious need.
For most people who find Go to be a compelling language, it excels for practical, real-world needs.
I have heterogenous priority queues where I want to push in JSON data and plain strings, I have custom iterators, concurrent data structures, default dictionaries, etc.
Seriously, look up Python's itertools and data structure modules and realize that there's a wealth of things that are useful and practical and, above all, reduce code size while preserving interface contracts and semantics. Go is completely unsatisfactory in this regard.
Haskell holds your hand and checks more things for you.
Haskell code runs from two times, to five times faster for CPU based code, and lets you scale to insanely higher concurrent workload in a safer way.
Why Go? Because marketing.
Smalltalk uses less code to do the same thing.
Smalltalk lets you offload bookkeeping to the runtime.
Smalltalk code often runs faster for actual business workloads.
Smalltalk lets you add features faster with fewer bugs.
Why Java? Because marketing.
What is the solution?
While I do agree that Generics can open up a whole new dimension of programming concerns. I think they are worth the additional syntactic complexity, because they allow you absolute accuracy when it comes to types. If we as a programming community want to ever get to the point where we have provably correct programs, or even reasonably correct programs, clear definitions of functions for an exact set of types is a necessity.
There are more synchronization features than channels in Go. Channels and switches solve most problems very well. However when another synchronization method is just simply required, check out: http://golang.org/pkg/sync/
Repeatedly, Go chooses the latter, and many people hail it while writing programs that crash on nil dereferences or duplicate their code for various basic types.
Here's the thing about the "Go sucks because Haskell is the best language ever" retort: Haskell has been around for decades longer than Go. It has made essentially zero impact, and even for the case of many of those who use it as the "my big brother" comparison against Go, it isn't a viable part of their daily toolset.
It's a theoretical solution that just makes for a nice checklist comparison against Go. You know this is true. We all know this is true. And everyone goes back to Java or C# or whatever else is your daily driver.
Yet people are making Go their daily driver. Solutions are being built, en masse, in Go. People are having great degrees of success with Go.
Isn't that weird? Might it be that Go adds primitives in a way that makes them usable and intuitive, without becoming strictly theoretical?
So people can keep posting these "Haskell, which I don't actually use in any credible way, is way better" articles, but they simply miss the point. They really do.
But generics are a fundamental tool to solve concurrency or composition. How do you propose to compose complex systems when you can't abstract on the type? How can you add new concurrency constructs that work safely for every type without generics?
Maybe if Go was dynamic or with full type inference, will like it more :)
I bet is great for the niche between C++ and Java, but not sure if I would want to use as a general programming language
No, Go's solution to generics is not interface{}. The moment you say that, you have lost. You are trying to fight Go and make it a language that it is not.
Always remarkable that such critiques always focus on the utterly trivial, while absolutely ignoring things like concurrency or composing complex systems. As always, the color of the shed is what the laymen want to argue about.