[ghughes]

Thanks for writing this up; it was something of a wake-up call from a recent bout of fanboyism, and I found myself agreeing with most of your examples. I'm still learning and I haven't found any of these things to be dealbreakers yet, but they're absolutely questionable design decisions when you consider that other languages already solved many of these issues (with good reason). I think there's a lot to like about Go but I'm worried that the language will die young because of religious inertia.

[vec]

That's the trap of Go. None of these are deal breakers. Yet.

It's notable that the vast majority of the above are complaints by experienced developers working on large projects that need to be maintained and expanded for years. They're not the sort of thing you notice over a weekend of tinkering on something fun, and they're not the sort of issues that beginners will run into under any normal circumstances.

All of that adds up to a honeypot for newcomers. The language has some deep issues, but they're not the kind of things you're likely to notice until you already have 200k lines written and it's too late to switch to something with a steeper learning curve. Saving two weeks of confusion when you're learning ends up causing a lifetime of headaches down the road once you're an expert.

In other words, Go is PHP for systems programmers.

[Merovius]

I hate this kind of "if only you'd write large programs and not just toys, you'd understand how bad Go is".

I write Go at work. I haven't counted in a while, but I guess the code of my team comprises significantly more than 200k lines (and that doesn't even count all the code I'm working on that isn't from my immediate team).

IMO, the more LOC you have, the more the design of Go becomes a godsend. Because it becomes much easier to dive into code you haven't written yourself.

But anyway, that's just my opinion, I just wish that people would stop this "anyone who disagrees with me just doesn't have the correct set of experiences" FUD.