List of articles complaining about Go

I have found this article. I would appreciate your comments. It is a little bit disturbing taking into account the author.

Source: Link

Why Go Is Not Good

I like Go. I use it for a number of things (including this blog, at the
time of writing). Go is useful. With that said, Go is not a good
language. It’s not bad; it’s just not good.

We have to be careful using languages that aren’t good, because if we’re
not careful, we might end up stuck using them for the next 20 years.

This is a list of my chief complaints about Go. Some of these are mentioned frequently, and some are rarely discussed.

I’ve also included some comparisons to both Rust and Haskell (which I
consider to be good languages). This is to show that all the problems
listed here have already been solved.

full article in the following Link

Now you may say “But why is Go not good? This is just a list of
complaints; you can complain about any language!”. This is true; no
language is perfect. However, I hope my complaints reveal a little bit
about how

· Go doesn’t really do anything new.

· Go isn’t well-designed from the ground up.

· Go is a regression from other modern programming languages.

First of all – just for reference, that article is from early 2014. Lots of conversation has happened around it. I suspect you can get you fill (to the thousands no less) of comments in various places.

It is a little bit disturbing taking into account the author.

Is this author famous in some way? I popped on his resume ( and it appears he is a college student? Not to say that college students can’t be incredibly accomplished, but I simply am not aware of his accomplishments, can you fill me in?


Thanks God, and thank you for your quick response.

ups! I thought the author was

Obviously the author doesn’t know some of the design decisions about Go, why this or why that.

Also that blog post should be called “Why I prefer Rust and Haskell over Go (ignoring why Go was created)”


You can find this and dozens of similar posts here.


don’t forget about this one.


I bet some of the people who wrote those articles are using Go nowadays

Great article :clap:

“Priceless” - a comment from that article

People really show how immature they are when they try to fit Go into their use case/taste and resort to criticizing rather than pick another language and move on.

But in general, if you don’t want the benefits of Go (simplicity, readability, fast compilation time, etc.) or you love/use heavily a feature that Go doesn’t have (generics, method overloading, etc.) then pick the right tool for your problem!

1 Like

Exactly —

I love Go…truly is a beautiful language in how it approaches things.

That being said, I’ve stopped using it for now and am focusing on NodeJS mostly because the support around Go is minimal. Every documentation out there you have to put on your genius hat to even begin to understand what was written, and its usually for something pretty basic that requires a ton of digging.

But probably the most important factor on why I switched is that everything needs to be built from scratch almost.
As an entrepreneur, my life is based on prototyping and improving on concepts quickly. Npm is a huge asset to Node that “Go Get” just hasn’t even come close to yet. The code already out there for Node allows you to add a huge amount of functionality in minimal time, where in Go, you have to build a lot of things from the ground up.

I think Go has a lot of promise, but the community is just so small right now, it’s a competitive disadvantage. If I were the Go creators, I would be focusing more on incentivizing community growth to increase the amount of ‘wild code’ out there for Go, rather than being laser-focused on building Go into an all supreme, all powerful language in the core package (which it very much is!).

Sure, NodeJS has a lot of packages enabling you to throw together a lot of other people’s code in a short period of time. Good luck maintaining that code, though. The downside of ultra rapid community growth is massive dependency graphs and things like the left-pad debacle. Ruby on Rails tends to lead to similar pains.

I agree that the documentation for Go could use a lot of improvement. Unfortunately the bar to entry seems pretty high.

Maintaining and building on a purely Node/Express/MongoDb stack right now with over 2,335 files, but maintaining it is more a function of maintaining comments and app-tree structure. The modules themselves you don’t need to maintain, just prevent your package manager from updating them to a major version update (eg. 2.3.6^).

I will say, callback hell can be exactly what it sounds, but then again you can also still utilize promises or with ES6 now, classes in OOP style.

I hated Node at first, too. But npm is undeniably the trump card over Go.

Thank you for sharing your view. I believe it is really valuable to point this out so things can change for the better.

I am really looking forward to seeing how things get better overtime. I believe the Go community will make Go shine very soon.

1 Like

I agree, like I said, it is a very modern and incredible language, but productivity always comes before technology. And right now, Node allows one to be more productive a lot faster.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.