Go is a good replacement for C and C++ for almost all purposes.
Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway.
The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.
For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't.
The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage.
Trying to target that with go would add a lot of extra challenge.
I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature.
The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.
You can use mark and sweep, you can us reference counting, you can use arenas, you can use local stack, you can use shared memory, you can have custom allocators for any object, you can avoid memory allocations altogether, and any combination of these.
C is the same. Java can do some of this, if you twist it hard enough. Go cannot. That's ok -- often, even most of the time, you don't care, and then Go is a fine language.
But C++ is useful in a much wider set of domains than many people think, because it offers a level of control that many other languages don't.
My favourite analogy? Go (etc) is like an Apple product: smooth, and shiny, and tries to be idiot-proof, but you can only do it the Go way. C++ is more Linux: a mess of incompatible, incomplete, infuriating things that let you do absolutely anything you want, if you invest the effort.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Go also has the stop-the-world GC problem, GC is great but it does have a price tag.
I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.
But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.
Go is very good for many things but it does not offer competitive performance for these types of applications because design elements that have a large impact on throughput are poorly supported.
Are you saying Go has portability problems?
Can you elaborate on that very surprising claim?
The compiler is a huge assemblage of C++ templates, stitched together with a little Python.
The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle.
But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators.
Go would be a great choice for the compiler.
Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...
Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.
Get a handle on your code quality, and put the language features to work to solve problems for you. Then Go will increasingly look pitifully inadequate.