If only that were actually true. I've done a lot of work porting C++ code to various different flavours of Linux and Unix as well as compiling stuff for Linux from working source and it's rare that things will "just work". Granted a lot of time the real pain point is manually having to deal with dependencies (even Go's old $GOPATH solution is better than the stanard C++ approach!). Then you have compiler flags, compile time options, distribution specific patch files, dependencies for the build scripts themselves, etc. And that's before you've even touched on compiler specific variations, language versions and undefined behaviours. There is a reason why the source-orientated repositories like FreeBSD ports, Gentoo's portage and Arch's AUR have wrappers around build scripts and it isn't because things "just work 99% of the time" ;)
Go does have its short comings, I'd be the first to admit that, but the actual reason I started writing Go was because it was far less brittle trying to write portable code than C++ and at the time I was having to do a fair amount of cross compilation on platforms of other CPU architectures as well as different host OSs (Rust wasn't mature at that point, .NET wasn't open source and I've never enjoyed working with Java so I thought I'd give Go a try)
really? I find that usually automake systems, despite how disgusting they are to deal with from a developer-standpoint, almost always tend to 'just work' from a user-standpoint.
I can't really speak very much for C++ systems, as I understand the dominant build system for that is CMake, which personally I have found completely abhorrent from a user-perspective. (I once tried to build a 32bit program on a 64bit system, and CMake completely and totally refused to do so! There were no override flag that actually affected the program, and it didn't look as if there was any standard place to inject flags to the compiler, I still have no idea how one goes about doing it, to be quite honest).
Go does have its short comings, I'd be the first to admit that, but the actual reason I started writing Go was because it was far less brittle trying to write portable code than C++ and at the time I was having to do a fair amount of cross compilation on platforms of other CPU architectures as well as different host OSs (Rust wasn't mature at that point, .NET wasn't open source and I've never enjoyed working with Java so I thought I'd give Go a try)