4 ms·

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

> 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.
        menaerus 4y ago
    - UncleMeat 4y ago
      "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.
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". ;-)

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

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". ;-)