|
|
|
|
|
|
by zigzigzag
3449 days ago
|
|
|
Yes but only in Go. There are projects that have successfully evolved APIs in not only source compatible but binary compatible ways over a period of decades. Win32 and Java are the obvious candidates. Not changing or deleting existing functions and fields is easy. The problem is that Go apparently doesn't let you reliably add things either. That is kind of a joke, how is anyone expected to be able to evolve an API if you can't even add things? Seems like the consensus is "well it doesn't happen often so it's not an issue" which is weak. Go isn't even trying for binary compatibility, the article is only talking about source compat! |
|
|
I don't believe this to be true. I'd say at least most languages/projects would have exactly the same kind of problems (some of them at runtime, some of them at compile time), it's just that in practice they don't really matter. So you don't know about it and it seems, to a casual observer, to work just fine.
> The problem is that Go apparently doesn't let you reliably add things either.
Neither does, at least, C. I'd guess that python also doesn't let you do it. I don't know enough about java, but I'd assume that it has the same problems.
What you need to understand is, that I applied an extremely nit-picky interpretation of stability. It's not like any of the things I mentioned are learned from experience or practical problems; I just understand the go type system enough and thought really hard whether there is an obviously correct and useful interpretation of API stability under its constraints and came up with a (mostly theoretical) result. Most projects in go that use SemVer apply a more generous and naive notion that works well enough in practice. C projects do exactly the same.