5 ms·

Go also has a very strict compatibility promise: http://golang.org/doc/go1compat http://golang.org/doc/go1compat This has been fantastic because I know my Go p

Go also has a very strict compatibility promise: http://golang.org/doc/go1compat http://golang.org/doc/go1compat This has been fantastic because I know my Go program won't break anytime in the foreseeable future (Go 2, if I were to guess, is still a decade away). Additionally, since the compatibility promise is not only in the language but also in the standard lib (to be expected, perhaps), I know that that isn't going to break either. It is pretty neat for a new version of a language runtime/compiler to be released and to just recompile your app and see dramatic improvements. This is in stark contrast to a language such as Ruby, where each version released, even when they say is backwards compatible, has been at least a minor headache to upgrade to due to behavioral differences. NOTE: I'm NOT NOT NOT comparing Go to Rust. Let's not open that can of worms.

millstone 13y ago
The golang link says "binary compatibility for compiled packages is not guaranteed between releases." Compare to, say, g++, which takes ABI compatibility very seriously, even to allowing you to select an ABI at compile time: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html (maybe Go has that feature too, I don't know). Anyways, I can see how from a Ruby perspective, Go's policy may appear strict. But from my C-family perspective, "we reserve the right to break ABI compatibility with each release" is a liberal policy, not a strict one. What's even neater is seeing your app get better without a recompile!
- nknighthb 13y ago
  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

The golang link says "binary compatibility for compiled packages is not guaranteed between releases." Compare to, say, g++, which takes ABI compatibility very seriously, even to allowing you to select an ABI at compile time: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html (maybe Go has that feature too, I don't know). Anyways, I can see how from a Ruby perspective, Go's policy may appear strict. But from my C-family perspective, "we reserve the right to break ABI compatibility with each release" is a liberal policy, not a strict one. What's even neater is seeing your app get better without a recompile!

nknighthb 13y ago
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.