3 ms·

Three main issues: 1) GCC didn't stabilize its C++ ABI until GCC 3.2, released almost 15 years after C++ support was initially added to GCC, and 4 years after

Three main issues: 1) GCC didn't stabilize its C++ ABI until GCC 3.2, released almost 15 years after C++ support was initially added to GCC, and 4 years after the ISO standard was finalized. (This is where I say "You damn kids get off my lawn!".) 2) At this point, ABIs simply don't matter for the Go in the same way. There is no dynamic linking in the original Go implementation, and you're not expected to be static-linking modules that you don't have the source for. That's just a basic assumption of the Go ecosystem: You have the source. Once the binary is built, it will continue to run so long as the kernel's userspace ABI remains compatible. The GCC Go implementation can, of course, implement a stable ABI if it wants, and that will probably become necessary if and when it supports dynamic linking (I'm not sure if it does yet, I've only used the original Go suite). 3) Go is designed to compile extremely quickly. Fast enough that you really shouldn't care if your program has to be recompiled. It should take seconds, not minutes or hours.

millstone 13y ago
1. Yep. A stable C++ ABI is hard, and limiting, and in a practical sense, C++ has never had one. You simply can't do something like return a `vector<int>` from a function and have it work reliably across different dylib versions. Your options here are "distribute the source" (Microsoft with MFC) or "don't use C++" (Apple with ObjC). 2. Right, they don't matter yet, because Go has pivoted to target servers instead of end user software. ABI compatibility is a first world programming problem: "we are so mature that we care about applications that have already been distributed to end users running correctly against later versions of libraries that will also be distributed to end users." Go isn't there yet, but it can cross that bridge when it reaches it. 3. Aw hell naw. If my end users have to recompile my software after reinstalling anything, then I've failed as an engineer.

millstone 13y ago

1. Yep. A stable C++ ABI is hard, and limiting, and in a practical sense, C++ has never had one. You simply can't do something like return a `vector<int>` from a function and have it work reliably across different dylib versions. Your options here are "distribute the source" (Microsoft with MFC) or "don't use C++" (Apple with ObjC). 2. Right, they don't matter yet, because Go has pivoted to target servers instead of end user software. ABI compatibility is a first world programming problem: "we are so mature that we care about applications that have already been distributed to end users running correctly against later versions of libraries that will also be distributed to end users." Go isn't there yet, but it can cross that bridge when it reaches it. 3. Aw hell naw. If my end users have to recompile my software after reinstalling anything, then I've failed as an engineer.