4 ms·

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

> 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.
- menaerus 4y ago
  And with the loose ABI model, how much more often they'd have to do that?
  - still_grokking 4y ago
    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.
    - menaerus 4y ago
      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?
      - still_grokking 4y ago
        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.
        menaerus 4y ago
        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.
        still_grokking 4y ago
        > 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.
- TheLoafOfBread 4y ago
  Except endless crying about hardware vendors not making drivers for Linux, because lack of stable ABI.
  - dralley 4y ago
    That's a completely separate problem.
  - UncleMeat 4y ago
    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."
  - still_grokking 4y ago
    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…
    - menaerus 4y ago
      There is no such thing as C ABI either.
      - still_grokking 4y ago
        I know. https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/ That's why I worded it with "ABIs". ;-)
jcelerier 4y ago
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
- menaerus 4y ago
  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.
  - jcelerier 4y ago
    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.
UncleMeat 4y ago
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.

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.

menaerus 4y ago
And with the loose ABI model, how much more often they'd have to do that?
- still_grokking 4y ago
  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.
  - menaerus 4y ago
    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?
    - still_grokking 4y ago
      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.
      - menaerus 4y ago
        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.
        still_grokking 4y ago
        > 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.
TheLoafOfBread 4y ago
Except endless crying about hardware vendors not making drivers for Linux, because lack of stable ABI.
- dralley 4y ago
  That's a completely separate problem.
- UncleMeat 4y ago
  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."
- still_grokking 4y ago
  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…
  - menaerus 4y ago
    There is no such thing as C ABI either.
    - still_grokking 4y ago
      I know. https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/ That's why I worded it with "ABIs". ;-)

jcelerier 4y ago

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

menaerus 4y ago
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.
- jcelerier 4y ago
  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.

UncleMeat 4y ago

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.