Comment by nindalf | Hacker News Reader

Comment by nindalf | Hacker News Reader

Parent Full thread

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/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/do...)

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...

And we all know how well Goggle is at keeping interest in its side projects.

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.

> 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.

> 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.

And with the loose ABI model, how much more often they'd have to do that?

Does it matter?

It's not like some dude needs to operate a crank for it to happen…

The computer does the actual work.

You know, a computer, this machine that can automate tedious tasks.

I think it does. It also opens another big hole of worms of maintaining and porting the existing software. And it also opens another question which is: how often should we allow to break the ABI? On regular basis, semi-regular basis, rare, very rare etc. And who defines this threshold?

What do you think the reasons are that ABI transition didn't happen already?

In an ideal world you would just need to "press a button". So this could happen every second day without any issue.

Of course things are more complex. Not everything is a Linux distribution where it's simple to rebuild the world.

But as the history of C++ shows people managed to life with this issue for a very long time. So it's not a show stopper in any way.

Even other very conservative languages like Java found a balance for breaking changes. The "problem" C++ has is more of a mental one, imho.

Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds. You could improve future version (or editions) but stay compatible to old ones at the same time.

Rebuilding trillions LoC that are deployed on literally every computer architecture, dozens of toolchains and OS's is a high impact and high risk problem with arguable benefits. Although it is technically possible, I don't think it is a process which "just happens" but it is a process which probably take years to be implemented on each and every platform.

So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.

> Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.

We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.

> Rebuilding trillions LoC that are deployed on literally every computer architecture, dozens of toolchains and OS's is a high impact and high risk problem with arguable benefits. Although it is technically possible, I don't think it is a process which "just happens" but it is a process which probably take years to be implemented on each and every platform.

It was mentioned already that Linux distributions are doing exactly this. On every major compiler update.

> So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.

Sure it's not trivial to set up. But it's possible and done so for a long time already.

Sure, things could be made simpler. For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)

> > Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.

> We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.

That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.

> It was mentioned already that Linux distributions are doing exactly this. On every major compiler update.

I guess you're aware not everything runs on Linux neither are all Linux deployments vanilla Linux deployments. At this point I think you're just intentionally ignorant or completely unaware of the world outside your bubble environment.

> For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)

Eh?

> That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.

It is an argument because suggesting to "easily introduce" the idea from another immature language which (1) is not proven and (2) which will take long long time before it does is wishful thinking, if not nonsense and far from reality. Rust "editions" do not solve the problem because, well, to begin with Rust doesn't have the problem of the same scale that C++ does.

We'll see what C++ will do in this regard but I wouldn't hold my breath. Disadvantages of breaking the ABI frequently currently outweigh the advantages and my opinion is that it will stay the same way for unforeseeable time.

Just as a tiny FYI, Rust's editions were proposed for C++ in 2019: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...

The outcome: https://github.com/cplusplus/papers/issues/631#issuecomment-...

Thanks for sharing the links but that's what I already said above in the comment.

> FWIW C++ also had similar proposal and it didn't went through AFAIK.

Ah I missed that! Well now you have the link showing you’re right :)

"How often" is indeed a decent question, but the ranges aren't too wide. It'd either be once per C++ release (every couple of years) or in some of the C++ releases (every five years or so). It isn't like if the committee decides it is okay to increase the widest integer type every week.

The reasons why the ABI transition hasn't happened already is because C++ has a historical position of breaking the ABI only very very rarely. This is, in part, a legacy from a world where it really was going to be frustratingly difficult to get new builds of their libraries.

Except endless crying about hardware vendors not making drivers for Linux, because lack of stable ABI.

That's a completely separate problem.

That's not the language ABI. This is the same term used for two different things. Language ABI is stuff like "this is how name mangling works", "this is how parameters are passed", and "this is the widest integer type."

That makes not sense as the C++ compiler ABI issue is independent of the OS.

Also the OS ABIs are usually C ABIs because there is no C++ ABI at all…

There is no such thing as C ABI either.

I know.

https://faultlore.com/blah/c-isnt-a-language/

That's why I worded it with "ABIs". ;-)

It's not the users who would recompile the world though, but the OS vendors. And really in 2022 with a threadripper, rebuilding the world is a matter of hours: my 2018 laptop can build a complete yocto environment from scratch, from GCC down to a Qt GUI running on X11 or wayland in 8-ish hours IIRC and is waaay slower than a TR, so really there's no excuse to not rebuild.

Previous ABI would still be provided for running proprietary software on Linux just like you can still install libstdc++5. On windows apps ship the c++ runtime along with them so nothing changes for old apps. MacOS users are used to compatibility breaking every 3/4 years and went through actual architecture changes once every decade so obviously changing c++ abi is minor in comparison

Please don't nitpick, I'm perfectly aware that the OS vendors would be the ones to recompile everything and users the ones to update their systems.

I don't agree with your sentiment as I read it as a little bit narrow-minded and I also consider the examples given to be bad, with design choices not quite feasible to be applied to generic and widespread community language such as C++.

> On windows apps ship the c++ runtime along with them so nothing changes for old apps

That combination is probably the worst from the both worlds so not exactly a shiny example.

> MacOS users are used to compatibility breaking every 3/4 years

Apple has always been special and I wouldn't consider their choices, which are almost exclusively aligned with what their business wants to achieve, to be something to be followed. They can do whatever they want because they're under total control of almost everything on their platform. Unless when they aren't and when they start to develop their own programming languages. Pretty much the same story as with Google.

Which users are you even talking about then? If you don't take into account Windows and macOS you remove 99.9% of the people which are going to be impacted by this (and I say this as a full-time linux user for a decade).

> That combination is probably the worst from the both worlds so not exactly a shiny example.

I really disagree, Windows's model of shipping DLLs along the app is the only one that works and does not cause headaches for the end-users who want to run their software from 15 years ago (e.g., me, my parents, my non-technical neighbours, etc) ; this is the only thing that matters, the end-user experience.

> If you don't take into account Windows and macOS you remove 99.9% of the people which are going to be impacted by this (and I say this as a full-time linux user for a decade).

How about server-side code powering virtually any service that we're using? I think that your 99.9% would quickly become 0.01%. Desktop is important but irrelevant in this regard.

> I really disagree,

I beg to differ. I think it's really terrible for reasons I have no time to dig in through right now. Many of them are in fact quite obvious.

> How about server-side code powering virtually any service that we're using? I think that your 99.9% would quickly become 0.01%. Desktop is important but irrelevant in this regard.

the huge huge huge majority of the software I use for doing, like, useful stuff, are offline. Internet could loose all interactive features tomorrow and be restricted to just displaying fixed hand-written HTML pages like it's 1993 and my day-to-day activities on my computer would not meaningfully change - making music with the software I develop, editing photos in Krita and Darktable, writing papers in TeXStudio, the occasionnal 3D / CAD project with Blender / KiCad / LinuxCNC, etc etc

In a world where dependencies are either delivered as source or through contract relationships with internet-connected businesses, I imagine that this is a normal thing. In the past you got code shipped to you on CDs. Today, I can get my dependencies via a network request.

If you don't have the ability to rebuild or otherwise get updated dependencies, you've got problems beyond ABI stability. "I cannot rebuild my dependencies" is unacceptable from a vuln management perspective, for example.

> And the programming landscape fragments further...

This process is called evolution.

There are only the two options when trying out new things: You fragment your language, or the language landscape.

Most languages don't want to have incompatible versions so as a result new languages get created during the evolution process.

While true, I feel the pace of evolution is too fast at the moment.

I am involved in scientific programming, and it's getting kind of crazy. This is a domain where programming is purely utilitarian, and what you are programming is more important. Unfortunately, new languages are driven by people who love programming for the sake of programming, and are often employed in big corporations that can absorb the financial cost of ecosystem duplication and fragmentation.

The time scientists spend on 'infrastructure' is increasing, and I'm not sure that's always a good thing. (Some is good, of course).

>I am involved in scientific programming, and it's getting kind of crazy. This is a domain where programming is purely utilitarian, and what you are programming is more important.

In my experience this leads to a lot of bad programming by people who only care about the utilitarian aspect, not about maintainability, user experience or failure modes.

Scientific programming would benefit the most from a stricter language that catches errors early on. Especially because most of the participants are usually not software engineers that have some semblance of a chance to catch errors in C++. Even they make a lot of mistakes.

In evolution, most branches are dead-ends (just like in programming languages). Carbon for example is by design an evolutionary dead-end designed to solve some problems for Google. They’re trying to sell it as a generic tool, but knowing Google’s track record it’s hard to say how many will bite.

> Carbon for example is by design an evolutionary dead-end designed to solve some problems for Google.

I would concur.

This shows actually nicely that the analogy to biological evolution matches well.

Google is building some kind of cave fish. Biology did also such things when they were right for a given ecosystem niche.

> 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.

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.

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.

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.

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.

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.

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 .

> 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.

Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.

> 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.

Reply on news.ycombinator.com