Conversely the more source you have the less important a stable binary interface is.
I use a lot of openbsd. The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability. However I have this enormous stable of open source software. and it all runs just fine.
> The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability
OpenBSD has the "benefit" of having everything in a single repository and when they break something they can also fix any uses in the same commit. I'm also certain that because of that they rarely actually break things that would need a huge number of updates, so that single repository also acts as a "do we really need this?" filter.
This is an exceptional case that doesn't apply to the overwhelming majority of projects out there which are projects that either expose an API/ABI of their own or projects that consume 3rd party API/ABIs that they have no control over.
> I have this enormous stable of open source software. and it all runs just fine.
This is because others are doing the work of keeping that software working on OpenBSD but once you encounter a situation where you need some software that hasn't been updated for a while to keep up with OpenBSD's API breakage, it'll become apparent that having access to the source code isn't some magic bullet and someone will need to do the work to bring it up to date.
Of course not having access to the source code is worse, but having the code is only one part of keeping things working, not the entire story. And IMO when we're discussing about projects that mainly or completely run by volunteers in their free time, i think it is a good idea to avoid situations where APIs and ABIs break so that limited free time is spent doing more useful and/or interesting things (i do not think anyone really likes fixing API/ABI breakage).
Yes, but not vice versa. Rust's language and standard library for example promises API stability, but not ABI stability. Since it doesn't promise ABI stability, the actual implementation can be radically different so long as the API you were promised still works and nobody has to go around "changing every single project" because there aren't any changes, for source code nothing changed.
On practice, ABI expressivity (not so much stability) is something very important that people have insisted on overlooking for decades because of that single-compiler fallacy.
To save C, we must save ABI - https://news.ycombinator.com/item?id=30660528 - March 2022 (128 comments)
But the title seems to be misleading. the title should be "to save c++, ....", c++ is not c nor is c the same as c++.
In the old link you provided, no one mentioned this is strictly about the c++ ABI.
>That's why I think C++ should be forked... Not to mention microsoft is probably the main culprit here.
But jokoon came close with the above quote.
> I'd just like to clarify that it's specific _compilers_ that produce code that complies with an ABI specification (or don't). Neither the C nor the C++ language standards specify an ABI format.
