3 ms·

Versions don't seem to mean anything anymore. Changing the calling convention with a minor release? Even if this change doesn't affect foreign functions (I cert

Versions don't seem to mean anything anymore. Changing the calling convention with a minor release? Even if this change doesn't affect foreign functions (I certainly hope so), it is all but guaranteed to break someone's code. What's so difficult nowadays with organizing a major release for such changes? Is it because of agile (TM)?

Noe2097 5y ago
In golang, everything is recompiled from source into a single standalone binary. There is no concept of shareable precompiled library -- a library is to be reused from its source code. In that world, calling conventions is not something considered public, so modifying it does not break any compatibility.
- pjmlp 5y ago
  There used to be one, but they took it out. https://github.com/golang/go/issues/28152 https://github.com/golang/go/issues/28152
vore 5y ago
I don't think Go has ever specified that a specific calling convention must be used, and it doesn't expose it very easily to the end user. I would argue that if you are writing code that depends on assuming the calling convention when it is explicitly not specified, that is a faulty assumption on you. https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/cmd/compile/internal-abi.md https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/c... This ABI is unstable and will change between Go versions.
- rightbyte 5y ago
  Now you are blaming the victim. Surely there is alot of ffi that will break.
  - p_l 5y ago
    FFI already goes through calling convention translation, since Go and C runtime aren't that compatible, even more so outside of Go's native environment (Plan9)
  - benhoyt 5y ago
    Are you sure? This would only affect C code calling Go functions, right? Apart from that being very rare (the other way around is more common using CGo), from the register proposal it looks like they've discussed and had ways to address the CGo issue. I haven't tried this though.
    - rightbyte 5y ago
      I am not too sure really. Trying to understand it I realized I know very little about Go internals.
tluyben2 5y ago
I see way too many breaking changes in minor versions; the js ecosystem is rife with this. But it is pretty common and mostly why I try to stick with .NET and Java. It is just incredibly weird installing a minor update with a security fix AND a breaking feature in a minor version. So much needless stress...
benhoyt 5y ago
The other replies give the answers: the ABI has always been an implementation detail, and Go binaries are static built from source, so this change won't matter. But just to add to that: I've been using Go for 4-5 years, and have never needed to know or care about its calling convention. It doesn't even affect people that write functions for Go in assembly ... because as the proposal says, "This will remain backwards compatible with existing assembly code that assumes Go’s current stack-based calling convention through Go’s multiple ABI mechanism." So the Go developers have put a fair bit of thought and effort into making this just work, even bending over backwards to make assembly libraries keep working.

Noe2097 5y ago

In golang, everything is recompiled from source into a single standalone binary. There is no concept of shareable precompiled library -- a library is to be reused from its source code. In that world, calling conventions is not something considered public, so modifying it does not break any compatibility.

pjmlp 5y ago
There used to be one, but they took it out. https://github.com/golang/go/issues/28152 https://github.com/golang/go/issues/28152

vore 5y ago

I don't think Go has ever specified that a specific calling convention must be used, and it doesn't expose it very easily to the end user. I would argue that if you are writing code that depends on assuming the calling convention when it is explicitly not specified, that is a faulty assumption on you. https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/cmd/compile/internal-abi.md https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/c... This ABI is unstable and will change between Go versions.

rightbyte 5y ago
Now you are blaming the victim. Surely there is alot of ffi that will break.
- p_l 5y ago
  FFI already goes through calling convention translation, since Go and C runtime aren't that compatible, even more so outside of Go's native environment (Plan9)
- benhoyt 5y ago
  Are you sure? This would only affect C code calling Go functions, right? Apart from that being very rare (the other way around is more common using CGo), from the register proposal it looks like they've discussed and had ways to address the CGo issue. I haven't tried this though.
  - rightbyte 5y ago
    I am not too sure really. Trying to understand it I realized I know very little about Go internals.

tluyben2 5y ago

I see way too many breaking changes in minor versions; the js ecosystem is rife with this. But it is pretty common and mostly why I try to stick with .NET and Java. It is just incredibly weird installing a minor update with a security fix AND a breaking feature in a minor version. So much needless stress...

benhoyt 5y ago

The other replies give the answers: the ABI has always been an implementation detail, and Go binaries are static built from source, so this change won't matter. But just to add to that: I've been using Go for 4-5 years, and have never needed to know or care about its calling convention. It doesn't even affect people that write functions for Go in assembly ... because as the proposal says, "This will remain backwards compatible with existing assembly code that assumes Go’s current stack-based calling convention through Go’s multiple ABI mechanism." So the Go developers have put a fair bit of thought and effort into making this just work, even bending over backwards to make assembly libraries keep working.