I am curious what led the author to be dismissive of Go in such a strongly negative manner. Lack of generics? Disagree with certain language design choices? Too many cuddly caricatures of gophers?
- low-level hardware control (c,D,...) implicitely concurrent
- explicitely concurrent higher level components (go, erlang maybe)Therefore I'd bundle it with C and D rather than Erlang.
I've been writing Go full-time for over 2 years and used to write mostly Java/C#, so I should know. When I started with Go and ported many of my personal Java applications, they all were much more maintainable and straight forward in Go.
Of course C had always been favorite language, and all I ever really wanted was a "modern" C, so I am probably biased.
Now, whether go turns out to be good at that task is another story
For example: the difference in initialisation of simple data types vs slices and maps. For an application programmer these are weird inconsistencies. But they make sense in the domain.
Or the way error handling works. Very tedious to have to do-check, do-check, and not be able to have automatic upwards delegation. But in system programming it's about robustness, not ease of development. A database server can't just restart if it has a file or memory problem. There needs to be a solution and it needs to be immediately next to the problem.
That being said, I've followed a similar pattern in writing Go web apps. I passed errors upwards from their originating site to the HTTP handler functions, because that was where the error handling was possible with the best context.