I tend to never emit any public criticism on blog posts as writing requires already a huge effort.
Yet, in my humble opinion, the arguments used in this post are not really strong.
1. Error Handling
I don't think there is anything wrong with error handling in Go (my opinion). Being an experienced developer, I like the fact that Go forces us to think about how to handle the error first and foremost.
If you decide to not handle an error, it's your decision as a developer, not the problem of the language.
Also, if you are afraid to miss one, there are plenty of static analyzers that will do the job for you to double check that you didn't miss any errors.
Then, the argument that panic is "against reliability in general" is not a strong one. First, you can always use recover to catch the panics. So the reliability argument does not stand.
Last but not least, panic means something went unexpectedly wrong. Hence, it might be instead a good idea to fail fast (in the development process I mean). That's just my opinion but if you disagree, as I said you can just use a global recover.
2. SQL
If you are more confortable with an ORM, just use an ORM like https://github.com/go-gorm/gorm
3. Development wheel
I'm not sure about your examples. For example the worker pool library?
Go offers strong concurrency primitives with goroutines & channels, I'm not sure why you would have to use a so-called worker pool.
Yet, in every single language you'll find libraries. I don't see why is it an issue. It demonstrates instead that the ecosystem is active.
4. Ecosystem
Talking about ecosystem...
It's strange that you are able to mention in the same post that Go is not ready for "Enterprise Systems" and that Kubernetes is built in Go.
Don't you consider Kubernetes as an "Enterprise Systems"?
It's a genuine question as I don't know what you mean by "Enterprise Systems". Kubernetes is a great piece of engineering, widely used in companies so I'm a bit puzzled here.
And I'm just mentioning Kubernetes. Needless to discuss about other systems (Docker, CockroachDB, Dgraph, etc.)
5. Community of the language is working in the right direction: simplification
One of the goal of Go since the very beginning was to propose a "simple" language. Simple in the sense of having expressive language, easy to learn, easy to read, etc. I don't understand what you mean here by "working in the right direction" in terms of simplification.
Conclusion
I'm not saying at all that Go is the perfect language that you should use in every single context. Just like any technology, it has some pros and cons.
Yet, I believe it's important to have a deep understanding of a technology before to draw some rushed conclusions like "Go is not ready for enterprise systems".
Of course, you can have your own opinion but it sounds more like a lack of experience rather than a real opinion based on multiple years of experience on the language.
Respectfully,
Teiva
