> But you could also flip that argument and say a good developer could write good code in any language so why bother with anything more sophisticated.

Because both inexperienced and experienced developers will be prevented from doing the wrong thing more often when using a better language.

I do agree with your point but this is about more than just language safety. The point the GP was making was more about expressiveness of languages (or at least that was how I interpreted it). You can have safety even in arguably unsophisticated languages (eg Visual Basic pre-dotnet). However it's true that some languages use their expression as a method of enabling developers to write less buggy software.

I mostly agree with you in regard the positive aspects of its tooling, however there are plenty of libraries in Go which use the void pointer, casting is a common thing and the whole duck typing is based on interfaces which is at least uncomfortable. On top of that Go is slower than C++ but more productive because of the lack of distractions which is why I agree with the "a boring language that's pleasant for just getting shit done".

Of course Go has its problems. There's no such thing as a perfect language because everyone has their own requirements. That's why I repeatedly state that a choice of language usually just boils down to personal preference.

I mean if performance Vs C++ was a primary concern then you're limiting yourself to quite a small subset of languages, most of which either have a steep learning curve and/or sacrifice security. This doesnt make sense for the majority of developers out there since very few people really need the performance of C++. That's not to say performance doesn't matter but rather Go's performance is more than adequate for most of the applications it is applied to.

To further that point just look at how I've used Go. I've written two FUSE file systems and a UNIX $SHELL in Go and found the performance to be good enough even on my relatively modest dev machine. I've also written log file parsers that can handle gigabytes or records in seconds. I'm happy with that level of performance because for me developer productivety matters a lot more since I have 2 small kids so hobby projects get very little time allocated to them. This means I'd rather prototype code then optimise later rather than spend comparatively longer building a POC that ultimately might never get enough time to see the light of day.

However you will have your own set of requirements which Go might underperform on and those reasons are as important to you as my requirements are to me.

This is why arguing about how some languages are bad or which are the best is about as worthwhile as arguing which colour is the "best".