While I would choose Go too, my specific complaint was about saying that Go is very cross platform and C/C++ are only sort of in a Unix way. Not only do I think Go has cross-platform issues wrt Cgo and that they only support gcc (but hopefully changing [0]), but that it is incorrect to say C/C++ is "sort-of cross-platform as long as it's unix". Those types of statements turn me off the article. So I stopped reading after that and the "real problems" statement.
I'm not sure it has much value to list places where Go may not solve the problem because we all know the limitations of our languages/platforms/runtimes. Among places Go is not the best: low-level embedded software, very performance critical software, software static correctness is more important than maintainability, etc. It's like saying Rust solves all real problems. While I guess mostly true, it doesn't mean too much to me. In general, I'm just finding these posts have little value to me anymore.
This is just disagreeing on definitions. You're assuming a particular definition of "cross-platform" and I think what they mean is that pure Go (using its standard library) is very portable. It's great if the standard library does what you need.
I'm not sure it has much value to list places where Go may not solve the problem because we all know the limitations of our languages/platforms/runtimes. Among places Go is not the best: low-level embedded software, very performance critical software, software static correctness is more important than maintainability, etc. It's like saying Rust solves all real problems. While I guess mostly true, it doesn't mean too much to me. In general, I'm just finding these posts have little value to me anymore.
0 - https://github.com/golang/go/issues/20982