4 ms·

I like the idea of Carbon and I hope to use it in the future. But wow, > We consider it a non-goal to support legacy code for which the source code is no long

by comex 2y ago

I like the idea of Carbon and I hope to use it in the future. But wow, > We consider it a non-goal to support legacy code for which the source code is no longer available is such a pejorative way to talk about ABI stability. Yes, supporting code you lost the source for is one use case for ABI compatibility. I guess it’s a real need that some people have. But it’s by far the most unsympathetic use case. It reeks of antiquated development practices. Plus, binaries with lost source are inherently a ticking time bomb since you won’t be able to port the code to new platforms or make any fixes. But what about all the other use cases for ABI stability? What if your vendor has the source code but doesn’t want to give it to you? What if you do have the source, but you want to be able to update libraries without rebuilding every executable that depends on them? Especially valuable if you’re building an operating system, Linux or otherwise. (There’s a reason that Swift spent so much effort on ABI compatibility.) What if you want to let people build dynamically-loadable plugins? (This one at least gets a brief mention in the Carbon goals document, albeit under the "legacy compiled libraries" section.) What if you just want to save build time via pre-built libraries? Don't get me wrong, I'm not against Carbon's decision to make ABI stability a non-goal. There are real tradeoffs in making ABI stability work. I'm just saying, if you're going to explain why you don't support it, don't dismiss the use cases for it by picking such a poor exemplar.

zozbot234 2y ago
There is a stable ABI for these purposes, it's called the C ABI. Or you could use modern "naked functions" support and set up your own function prologues, epilogues and parameter passing in assembly code.
- pjmlp 2y ago
  Its clunkiness in modern times is why I rather deal with COM boilerplate, or OS IPC. We deserve something better than 1970's view of OS ABIs.
JackC 2y ago
I think the distinction is these usecases require an ABI, but not the same ABI? You could in theory migrate both sides to Carbon for all of these, if it was worth it.
chandlerc1024 2y ago
(Carbon lead for context) I think you're missing the point of the example in a major way... Personally, I care about finding ways to support a bunch of these other use cases where we can and in good ways. Especially things like build times, dynamically loaded plugins, and vendored libraries. I think we can and _need_ to find reasonable solutions to those. The specific example is the only one called out because it's the only one that is fundamentally a non-goal. The other use cases I think we can find good ways to support, but they may not look like a stable ABI for the entire language. Maybe a designated subset or surface which is designed to have long-term link compatibility in some way, etc. Removing that specific use case is important because it opens up more candidate solutions in the space. And to be clear, this isn't a straw-person use case. This specific wording and use case was a response to that use case being actively supported by the C++ committee on several occasions.

by comex 2y ago

zozbot234 2y ago

There is a stable ABI for these purposes, it's called the C ABI. Or you could use modern "naked functions" support and set up your own function prologues, epilogues and parameter passing in assembly code.

pjmlp 2y ago
Its clunkiness in modern times is why I rather deal with COM boilerplate, or OS IPC. We deserve something better than 1970's view of OS ABIs.

JackC 2y ago

I think the distinction is these usecases require an ABI, but not the same ABI? You could in theory migrate both sides to Carbon for all of these, if it was worth it.

chandlerc1024 2y ago

(Carbon lead for context) I think you're missing the point of the example in a major way... Personally, I care about finding ways to support a bunch of these other use cases where we can and in good ways. Especially things like build times, dynamically loaded plugins, and vendored libraries. I think we can and _need_ to find reasonable solutions to those. The specific example is the only one called out because it's the only one that is fundamentally a non-goal. The other use cases I think we can find good ways to support, but they may not look like a stable ABI for the entire language. Maybe a designated subset or surface which is designed to have long-term link compatibility in some way, etc. Removing that specific use case is important because it opens up more candidate solutions in the space. And to be clear, this isn't a straw-person use case. This specific wording and use case was a response to that use case being actively supported by the C++ committee on several occasions.