Hacker News new | past | comments | ask | show | jobs | submit login

Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code.

Most people I've seen, that are frustrated with go, are people who want to have an impact on the community by writing a package that a) solves a simple-ish problem with the simplest API possible (e.g. "password-hashing libraries") or b) solves a complicated-ish problem in the most general way possible (e.g. "generic containers" or "graph algorithms"). As go makes both of these very hard, these kinds of people get frustrated with it.

go generally agrees with people who want to solve complicated specific problems, e.g. "I want to find all dead links on a website", because it gives you a relatively straight way from A to B.

Is there any detailed article on this topic that you know of?

The canonical answer is [0], though unfortunately, that's not very good to illustrate this specific point :) I came to this conclusion from reading the golang-{nuts,dev} mailing lists and whan pops up in the community. The usual answer to a proposal of a new language feature (most famously some form of generics) is "what real-world problem is this trying to solve and maybe we can solve it in other ways". And "real-world" always means "real-world", i.e. code that is currently running in some real project out there. And the answer of the people propositioning is almost always something in the neighborhood of "I want to write a foo-library, that makes bar simpler".

I remember reading an article a while back by someone explaining exactly that very well, but I can't seem to find it…

[0] https://talks.golang.org/2012/splash.article

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact