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

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.