5 ms·

The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in th

The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...). The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.” The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google. That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright. This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang. Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...)

fxtentacle 4y ago
My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.
- bluGill 4y ago
  Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.
  - fxtentacle 4y ago
    Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
    - bluGill 4y ago
      Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .
- CoastalCoder 4y ago
  > If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.
  - fxtentacle 4y ago
    Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
    - CoastalCoder 4y ago
      > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.
sseagull 4y ago
There was a bit of discussion yesterday about 'immaturity' in the programming community. To me, this is an example of a broader immaturity. Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way. Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...
- not_the_fda 4y ago
  And we all know how well Goggle is at keeping interest in its side projects.
- UncleMeat 4y ago
  A lot of people don't think that a frozen ABI is for the greater good of the community. It is specifically good for the set of people who cannot recompile their dependencies or cannot recompile their binaries. That's an ever-shrinking population.
  - menaerus 4y ago
    > That's an ever-shrinking population. Is that really so? I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. Like, all of the sudden all the software that we use on our machines becomes subtly broken since, well, new version of C or C++ runtime library is now out. I really don't see how this can be considered as a reasonable thing to do and therefore I understand and support the slow and careful ABI increments because the language is there to serve the goal which is beyond being a hostage to a handful of big players.
    - still_grokking 4y ago
      > I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. > I really don't see how this can be considered as a reasonable thing to do […] Well, Linux distributions do exactly this, since decades, and it works just fine.
UncleMeat 4y ago
> The committee chose an endorsement of indefinite ABI stability. It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.
- JonChesterfield 4y ago
  The longer the committee holds onto the current status - that we neither promise stability nor will break it - the more users who value performance over never running a compiler will leave. The remaining members are increasingly likely to vote in favour of stability, despite that meaning performance overhead. By induction, the expected result should be that stability is chosen over performance in the future as well.
  - UncleMeat 4y ago
    I think that is indeed true, but if that is the future I'd really like the committee to actually say it. Right now, the folks who really do depend on being able to link against code compiled a decade ago can't fully trust that the status quo will remain.

fxtentacle 4y ago

My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.

bluGill 4y ago
Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.
- fxtentacle 4y ago
  Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
  - bluGill 4y ago
    Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .
CoastalCoder 4y ago
> If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.
- fxtentacle 4y ago
  Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
  - CoastalCoder 4y ago
    > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.

sseagull 4y ago

There was a bit of discussion yesterday about 'immaturity' in the programming community. To me, this is an example of a broader immaturity. Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way. Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...

not_the_fda 4y ago
And we all know how well Goggle is at keeping interest in its side projects.
UncleMeat 4y ago
A lot of people don't think that a frozen ABI is for the greater good of the community. It is specifically good for the set of people who cannot recompile their dependencies or cannot recompile their binaries. That's an ever-shrinking population.
- menaerus 4y ago
  > That's an ever-shrinking population. Is that really so? I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. Like, all of the sudden all the software that we use on our machines becomes subtly broken since, well, new version of C or C++ runtime library is now out. I really don't see how this can be considered as a reasonable thing to do and therefore I understand and support the slow and careful ABI increments because the language is there to serve the goal which is beyond being a hostage to a handful of big players.
  - still_grokking 4y ago
    > I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. > I really don't see how this can be considered as a reasonable thing to do […] Well, Linux distributions do exactly this, since decades, and it works just fine.

UncleMeat 4y ago

> The committee chose an endorsement of indefinite ABI stability. It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.

JonChesterfield 4y ago
The longer the committee holds onto the current status - that we neither promise stability nor will break it - the more users who value performance over never running a compiler will leave. The remaining members are increasingly likely to vote in favour of stability, despite that meaning performance overhead. By induction, the expected result should be that stability is chosen over performance in the future as well.
- UncleMeat 4y ago
  I think that is indeed true, but if that is the future I'd really like the committee to actually say it. Right now, the folks who really do depend on being able to link against code compiled a decade ago can't fully trust that the status quo will remain.