Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck.

What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them.

I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem with CoffeeScript (conflation of declaration and assignment + scope rules) and the authors' refusal to admit that there is a problem also made me dismiss it entirely.

Every language/platform has problems. But not every language is in denial of them. We should all avoid those that refuse to acknowledge their problems - because that points to a much deeper, much more serious problem - a problem that cannot be eradicated with technical means.

> I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them.

For what it's worth, I have had a similar experience.

One time I expressed a personal opinion on G+ about something I don't like about Go personally. A Go fan re-shared this in the Go community and it turned into a debate. https://plus.google.com/+RalphCorderoy/posts/ZfaM1a21tyW

People argued that my concern was theoretical and would not happen in practice.

Then, by chance, someone wrote a totally unrelated blog article about their actual experiences writing Go. The article was overall positive about Go, but among their list of dislikes from using it in practice was exactly the concern I had voiced.

I posted this to the thread and the response I got was: "When I read that, he didn't give an example of it coming up. Again, it seems purely hypothetical.\uFEFF"

Apparently a person writing about their experiences who says "There are a few things about Go that I'm not super happy about, and that tend to bite me from time to time," and then talking about problem X, is not enough evidence that X actually happens.

I took from this experience that, at the very least, there is a strong bias against admitting problems.

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8...

https://github.com/clipperhouse/gen

I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

Everything in there listed as impractical in Go is possible in D without external tool, with just regular meta-programming:

- generating parsers from grammar https://github.com/PhilippeSigaud/Pegged

- embedding files as array of bytes:

    ubyte[] = import("file.jpeg");\n

- generating tables at compile-time with CTFE

Instead of copying what works the Go leaders pretend it doesn't work.