Rust editions are no different from selecting language versions, on their current state they require compiling from source with the same compiler, a very tiny set of language changes that might be supported.
> Each project can opt in to an edition other than the default 2015 edition. Editions can contain incompatible changes, such as including a new keyword that conflicts with identifiers in code. However, unless you opt in to those changes, your code will continue to compile even as you upgrade the Rust compiler version you use.
Now granted it’s entirely possible that a given compiler version accidentally broke comparability when building in a different mode - that’s a bug. It’s also possible that this model does have a limit as to how breaking of a change the editions can have (eg probably the ownership model can’t change drastically) which is maybe what you’re trying to say? Certainly if I recall correctly there have been breaking changes in editions.
[1] https://hkalbasi.github.io/mdbook-ra/appendix-05-editions.ht...
Other languages, like Java, C, C++, C#, F#…, also embrace binary libraries and multiple implementations.
Rust editions currently don't have an answer for such scenarios.
Which isn't really much of a problem given that the ecosystem is built around cargo compiling from source.
Aren't they? Can you choose to compile Java 17 with Java 7-8 syntax, but still make use of Java 17's other features which don't break backwards compatibility? As far as I have understood, that's possible with Rust (though I might be wrong, I've never really tried using an older edition).
One lesson for Borland days is that I rather use the languages that are on the box than dealing with extra complexity of third parties in the platform.
My point of view is not always what wins out, and there is good to learn new approaches in programming that can be latter applied to the daily tools, but that is how I see things.
The Borland example is confusing. The way I remember it their Pascal and C++ support was equally official. BC++3 was comparable to TP6 though the latter was less resource hungry (and at <700KB fit a single FD). Then for many years Delphi was well ahead of C++ Builder. But in the end professionally C++ skills were much more valuable.
Ten years ago I hoped that ORCL would acquire Typesafe and make Scala supported officially the way MSFT did with F#. Instead they left the space open for Kotlin to appear. And then antagonized GOOG into making it a juggernaut. There must be some Innovator's Dilemma-style explanation here but as a developer I regret it.
As a side-note I believe Martin made a huge mistake by allowing Haskell fans to highjack the narrative. His original strategy reminds me Elon's a little. Make industry finance and popularize high-impact type system research by using its impressive end result. Investing in Scala ten years ago prepared me well for Kotlin and modern Java (not to mention a few years of data engineering jobs around Spark and ML).