News for hackers. Stuff that matters.
Re:Pip has dropped support for Python 2 by tsimionescu on Sunday January 24, 2021 @04:30AM (#25890628)
I think you misunderstood. C++ doesn't even have an official ABI, nevermind having a stable one. ABI changes can and do happen in many C++ implementations (and there is no compatibility across implementations - you can't link a library compiled with clang to one compiled with MSVC). You can't generally expect to link together libraries compiled with different major versions of the same toolchain, though this may be supported by some toolchains.

Instead, Rust has defined an ABI and has committed to never breaking that ABI. Editions support API-level changes, but the ABI won't change.

Re:Pip has dropped support for Python 2 by steveklabnik on Sunday January 24, 2021 @10:35AM (#25892841)
Rust has not defined an ABI. You're misunderstanding how the edition mechanism works. Each compiler knows how to turn source code of any given edition into the same internal IR, but that's purely internal. You still cannot compile an rlib with Rust compiler version 1.X and use it in a program compiled with Rust compiler version 1.Y. You can compile an rlib with Rust compiler version 1.Z that uses edition 2015 and use it in a program compiled with Rust compiler version 1.Z that uses edition 2018.
Re:Pip has dropped support for Python 2 by pjmlp on Sunday January 24, 2021 @04:45AM (#25890691)
That is news to me, where is the ABI specified, given that cargo is yet to support binary crates?

> you can't link a library compiled with clang to one compiled with MSVC

You surely can, provided it is made available as DLL or COM.

Re:Pip has dropped support for Python 2 by fluffything on Sunday January 31, 2021 @02:30AM (#25976910)
Rust actually supports multiple ABIs and you can pick which one to use.

The one I use for maximum portability is the C ABI defined in the ISO C standard and on the platform docs (eg the Itanium ABI specified eg in the x86psABI document on Linux).