> Depending on the application, the utility of the ecosystem often outweighs the constraints of the language.
This is the one part where I generally tend to disagree. Basic language constraints are immutable, whereas ecosystem pain points can be fixed if people care enough. Everything you cited is true, the Go people seem to have done a great job at making the ecosystem convenient to use, but language issues are the one thing users can't fix on their own. The C++ ecosystem is fragmented, everyone has their own preferences and we'd all like to see it improved, but individual developers (as well as organizations, just look at Google's internal ecosystem) find a way to make it work well. If there's a dealbreaker in language design, on the other hand, there's just nothing you can do.
I absolutely agree; this is why I prefixed with "Depending on the application". If your application doesn't run into the prohibitive language issues, then you can benefit from the ecosystem with minimum drawbacks.
It's also worth noting that these "prohibitive language issues" can be solved with code generation in the worst case, and while this is often unjustifiably tedious, it's still far simpler than basic C++ project management (maintaining CMake, integrating an editor into your project, setting up testing, cross compiling, dealing with templates and compiler errors, etc). And I say all of this as a former C++ developer. If you can make C++ work in the basic cases, Go's worst case is still far nicer for all but the most performance-demanding applications.
I'm biased due to the performance constraints I work with and actually liking templates for the most part (apart from a few silly restrictions on specialization), but here's how I've solved some of those pain points for myself. I can't stand CMake, but quite enjoy using Meson (though small projects are just fine with a simple build script in bash or whatever you prefer). Error messages and editor integration are largely fixed by the Clang ecosystem, which have also enabled some excellent editor plugins (I use EasyClangComplete for Sublime, there are equivalents for every major editor now). When I care about Windows compatibility, I also use VS2017, which is a great improvement over previous versions and doesn't impose major constraints in terms of standard compliance any more. Perf and VTune satisfy all of my profiling needs.
Overall, I feel like the ecosystem utility / tooling situation has improved hugely over the past few years, to the point where it's comparable to any other language out there, though at the expense of requiring some user effort in choosing tools and getting a bit used to them. That's just my personal opinion, though, YMMV.
This seems reasonable. It's been more than a few years since I got out of the C++ game, and I never really kicked the tires on Meson. I'm truly happy to hear that things are improving for C++; I really liked the language (complex as it was), but I couldn't get anything done because of the ecosystem.
This is the one part where I generally tend to disagree. Basic language constraints are immutable, whereas ecosystem pain points can be fixed if people care enough. Everything you cited is true, the Go people seem to have done a great job at making the ecosystem convenient to use, but language issues are the one thing users can't fix on their own. The C++ ecosystem is fragmented, everyone has their own preferences and we'd all like to see it improved, but individual developers (as well as organizations, just look at Google's internal ecosystem) find a way to make it work well. If there's a dealbreaker in language design, on the other hand, there's just nothing you can do.