Read the damn Editions RFC. The community agreed that no semantics or ABi breaking changes will land to Rust,
EVER.
This is not a lesson from Py th on, but from C++, which introduces breaking changes every single release, which are much smaller than Python but still a pain in million LOc code bases.
If that ever happens, it was agreed that the result would be a different language, with a different name.
That is, editions don’t have this problem because the FUD that you are trying to spread every single time this issue comes up cannot happen, by design.
Your argument “Rust editions don’t solve this problem because they don’t handle semantic or ABI changes” is false,
because in Rust there CANNOT be any semantics or ABI changes, and editions handle this situation just fine.
In the context of Python 2 vs 3 this argument makes even less sense, because editions allows combining libraries from different editions ina forward and backward compatible way without issues. Source: work on multiple >500kLOC Rust code base and one >1 million LOC and they all use crates from all editions, and mix & match them, without any issues, doing LTO across them, using dynamic libraries, and all possible combinations of binaries across 4 major platforms.
The problem is there, the fact you choose to ignore expectations of C and C++ enterprise developers using binary libraries across language versions is another matter.
You call it FUD, I call it hand waving.
I want Rust to succeed and one day be available as official Visual Studio installer language, but apparently unwelcome points of view are always pointed out as FUD and attacks.
When cargo does finally support binary crates, I will be glad to be proven wrong when linking 4 editions together into the same binary, just like I do with DLLs and COM today.
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.
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.
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).
I didn’t chose to ignore that. I compiled a Rust binary library 4 years ago, it still works without recompiling today on a dozen of operating systems and toolchains that did not exist back then.
Try doing the same with C++.
I really believe you when you say that you are clueless about how to do this, since you don’t seem to have any idea about what you are talking about, and all your posts start with a disclaimer about that.
But at this point the only thing I have to tell you is RTFM. Doing this is easy. HackerNews isnt a “Rust for illiterates” support group. Go and read the book.
Read the damn Editions RFC. The community agreed that no semantics or ABi breaking changes will land to Rust, EVER.
This is not a lesson from Py th on, but from C++, which introduces breaking changes every single release, which are much smaller than Python but still a pain in million LOc code bases.
If that ever happens, it was agreed that the result would be a different language, with a different name.
That is, editions don’t have this problem because the FUD that you are trying to spread every single time this issue comes up cannot happen, by design.
Your argument “Rust editions don’t solve this problem because they don’t handle semantic or ABI changes” is false, because in Rust there CANNOT be any semantics or ABI changes, and editions handle this situation just fine.
In the context of Python 2 vs 3 this argument makes even less sense, because editions allows combining libraries from different editions ina forward and backward compatible way without issues. Source: work on multiple >500kLOC Rust code base and one >1 million LOC and they all use crates from all editions, and mix & match them, without any issues, doing LTO across them, using dynamic libraries, and all possible combinations of binaries across 4 major platforms.