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.
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.
(I remember it being talked about on the Go list – but can’t find it)
It is a little bit disturbing taking into account the author.
Is this author famous in some way? I popped on his resume (http://yager.io/resume.pdf) 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?
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!
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.
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.
