I bow to your technical points, I stand corrected; however in terms of problem space, actual production use-cases, do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach — think that it was designed in-house by/for Google, which is a giant pile of microservices at its core, with thousands of engineers interacting on the base.
I mean Go is a systems/middleware dream, but I wouldn't start there for BI, enterprise-y, "expressive" code. I'm not sure to which extent Go at Google replaced Java or C++ but my money is on the latter.
I'm not stating this as "fact", really open to the discussion! I have much to learn, and this is not speaking from experience but rather perception, extensive but nonetheless second-hand knowledge.
Regarding Rust, good points, good food for thought. Thanks.
Edit notes:
[1] "no generics!" — "wth error handling `if err != nil { return err }`" — which are godsend to other devs, other domains.
> do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach
Hard to say; it's important to recognize that Golang is still young, compared to Java/C#; the generics subject is very much open.
My very general idea is that Golang is a more modern language, specifically, because it was build from the ground up to tackle more modern problems (concurrency and networking first of all).
Also it's important to consider that there is an ecosystem beyond the pure language design - single binary approach, compiling time, etc. (I also have not-so-fond memories of XML-based build tools, I prefer Makefiles).
I've read of people writing fairly low-level stuff in Gol. I still personally prefer a proper systems programming language for that type of work. On the other hand though, many C/++ tools/projects originated when there wasn't so much availability of compiled languages - therefore the choice of such languages was not ideal; definitely, in the same conditions, Golang would have probabaly be better suited (but imagine how large it would be an Ubuntu distribution where all was written in Go ;-)).
I mean Go is a systems/middleware dream, but I wouldn't start there for BI, enterprise-y, "expressive" code. I'm not sure to which extent Go at Google replaced Java or C++ but my money is on the latter.
I'm not stating this as "fact", really open to the discussion! I have much to learn, and this is not speaking from experience but rather perception, extensive but nonetheless second-hand knowledge.
Regarding Rust, good points, good food for thought. Thanks.
Edit notes:
[1] "no generics!" — "wth error handling `if err != nil { return err }`" — which are godsend to other devs, other domains.