Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures).
In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languages really bad or annoyingly painful for others.
For me, Go is my number one tool for creating command line apps now. I get immediate cross-platform cli tools with zero headache. Its also a really nice fit for lower level networking/distributed applications where you are working with byte protocols (things like mozillas heka, or docker, proxy servers, chat clients, etc), the networking server-side stuff where you would probably have used C++/Java.
My recommendation would be, if you work a lot on this kind of software seriously start using Go, you will love it and think everyone is crazy for hating on Go.
The problem is I think lots of people are trying to use Go for stuff it is not designed for and where, compared to the alternatives, it is a rather bad fit. For instance Go is zero fun for: Compiler Programming (Haskell/C++ have way better tooling), Games (libs are one thing but Go cannot compete with C++ perf here), Desktop GUI apps (Just use QT), Mobile Apps, and Web Programming (take your pick of python,ruby,js,clojure,php - your life will be much easier), Hardware/Low Level Systems programming (Obviously you can't use a GCed lang here).
I haven't found another area where I really like programming in Go besides CLI and networking I mentioned above. It could have another sweet spot I've missed...
> unless of course you're a masochist and ... want static typing
Some people say to prototype in a dynamically-typed language and then switch to a static language later. Dynamic typing might save keystrokes, but typecasting and type-checking do require lots of typing, and who cares that much about a few hundred extra keystrokes anyway?
Some people say to create whole, large apps in dynamically-typed languages, but those people clearly haven't tried modifying or debugging code bases in those languages that weren't created with utmost discipline and 100% test coverage.
So with 10 years of web programming experience, I'd emphatically argue that masochism is not using static typing.
I have warm, happy dreams of a future where there's a great alternative to the dynamic/weak web languages of today. There are already some great entrants, but nothing has reached the massive popularity of existing languages yet.
I think you left off the key part of his point, namely "when recursively parsing unknown json data structures".
json parsing in Go uses reflection, which not only means it is slow, but if your input is not consistent (like say.. a log file with 20 different possible formats), it can be quite painful and very verbose.
I believe you that it's slow, but I'm not sure I know enough to understand how it's a knock against Go as a language. Is it something that's impossible to fix without changing the syntax?
Anyway, you could always use a highly-optimized JSON parser written in C[1], so it shouldn't be a deal-breaker for anyone interested in Go.
In my own testing it was faster (even with ffjson) to pre-clean my data in cpython or pypy, and then emit some intermediary format (like capnproto) for the go code to consume. I was parsing huge files full of lots of non-uniform json with many formats.
For most use cases though, the fact that json is "slow" is probably not a huge factor, as network IO or something else is likely the gating factor. For those uncommon cases though, I wish the native json lib in Go was faster.
"Web Applications" are often made up of parts now. So while php/ruby/python are faster to develop for most things - writing the websocket handler or AJAX polling API in Go makes a LOT more sense given the performance of these crucial parts of the application.
I am currently using the massive PHP + Node.js ecosystem for most of the application and Go for the critical communication parts.
I second this approach of mixing components. While I have not personally used Go, I have used Tornado and C++ to handle complex networking code, and I'd never use these as a complete substitute for "web application" development.
My current company's web API is built using Django, which may come as a surprise since we also do realtime stuff, but that's the benefit of mixing the best tools for each job.
In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languages really bad or annoyingly painful for others.
For me, Go is my number one tool for creating command line apps now. I get immediate cross-platform cli tools with zero headache. Its also a really nice fit for lower level networking/distributed applications where you are working with byte protocols (things like mozillas heka, or docker, proxy servers, chat clients, etc), the networking server-side stuff where you would probably have used C++/Java.
My recommendation would be, if you work a lot on this kind of software seriously start using Go, you will love it and think everyone is crazy for hating on Go.
The problem is I think lots of people are trying to use Go for stuff it is not designed for and where, compared to the alternatives, it is a rather bad fit. For instance Go is zero fun for: Compiler Programming (Haskell/C++ have way better tooling), Games (libs are one thing but Go cannot compete with C++ perf here), Desktop GUI apps (Just use QT), Mobile Apps, and Web Programming (take your pick of python,ruby,js,clojure,php - your life will be much easier), Hardware/Low Level Systems programming (Obviously you can't use a GCed lang here).
I haven't found another area where I really like programming in Go besides CLI and networking I mentioned above. It could have another sweet spot I've missed...