There are no channels, there are no lightweight/green threads, there's no standard HTTP library, no standard crypto libraries, no standard test framework. For certain classes of applications this makes Go significantly more productive and significantly less bug/error prone. Not to mention compile times.
Even the nicest things in C++14 suffer from backwards-compatility-ism i.e. awkward syntax, and endless incomprehensible garbage output from the compiler when you make an error e.g. inside some complex templated code. As C++ devs we manage to live with that stuff but it still sucks.
Even if your code uses some nicer subset with standard libraries you typically need to interface to a whole range of things that do not comply with that subset. Be that something like a Cassandra driver that uses libuv or OpenSSL with its native C interface. Any C++14 beauty that may have existed is gone and your code is now subject to all those subtle memory management, buffer overflow, and concurrency issues.
I used to think garbage collection was garbage but I've start to appreciate how much simpler it makes my life (Even over RAII smart pointers) for very little cost in Go.
That said there are certainly some classes of applications where there's no substitute to C++. It's also much nicer than it used to be. But it shows its age.
The fact that there is a nice subset of C++ which works well is not a valid argument, in practice. As you say, you are forced to include in your projects a lot of libraries, each assuming its own definition of what this subset is, and the union of those subsets can be a monster.
I usually build embedded systems, desktop apps, and even some higher end computing applications. I use QT in conjunction when I need most of that stuff you mentioned, as that framework makes it easy. Also,
> there's no standard HTTP library
I mean, there isn't a standard library, but cURL is easy to use.
I've used C++ with Qt in building embedded applications and my experience was mostly good. Then again Qt had its own types which were incompatible with C++ and a fair bit of work was getting more or less standard C++ mated with Qt. I remember writing a lot of glue code that used Boost.Signals2 ...
On one hand it's true that people who still see C++ as C with classes and don't use things like lambdas, algorithms, smart pointers, STL data structures, are contributing to some hate/misunderstanding of C++. On the other hand, C++ developers who do use the modern features get used to all the quirks and don't understand why others don't see what we see ;) So we just maybe std::move, or inherit from enabled_share_from_this without thinking twice and know the difference between && and & and the new lambda syntax but really, as a developer, most of the time, why should I care? To some extent a camel can't see its own hump.
What you're saying is basically exactly what I would have said 2 years ago before I started using Go more heavily. Now it's mostly C++ because I have to and Go because I want to... Not that Go is perfect but the stuff that it does well it also does easy.
By all means, if your developers are unwilling to learn modern C++, use Go - it's easier to learn. I agree that's it particularly well geared for any network IO-heavy server. C++ can give you better performance, but it probably requires 5 times the effort.
Unless you want windows compatibility. GP isn't necessarily doing web development from the description though, just something that uses a network.
I also didn't mention earlier that curl is probablly not a replacement for an http library. There is some overlap in use cases but neither can replace the other.
I'm pretty sure the gp was instead suggesting that you should use libcurl, which is the library that powers curl-the-command-line-utility.
So for some sanity, I always spent some days writing sane, type safe, C++ wrappers.
But this always fails flat when working in teams that don't share the same quality goals, without directives from above.
Thought-trough, modern C++ code is IMHO quite often more readable, elegant and generally more pleasant than anything I've seen in C# or Java so far. But it's all hampered by the poor code some people ham-fisted in before or afterwards...
So, at least for me, C++'s biggest drawbacks are many of its users, not the language itself. Interestingly, that's something thad e.g. the Python community seems to have way more success managing, although Python as a language checks almost all boxes that should - in theory - foster quick hacks...