4 ms·
Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of the FAQs, so: How long do you (the Rust community) expect Rust to remain backward
by mook 12y ago
Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of the FAQs, so:
How long do you (the Rust community) expect Rust to remain backwards-compatible? That is, once 1.0 ships, on what sort of approximate timescale would significant effort be made to ensure code that worked with the initial release (assuming no experimental features / libraries in use) would keep working? On the order of months, years, decades?
I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. But given e.g. the prevalence of Python 2 versus Python 3, it seems like there's quite a lot of people who think similarly.
Background: I used to write Firefox extensions and things like that. Stopped being active around Firefox 4, when they declared that they are fine with breaking backwards API compatibility (and, IIRC around that time or soon after, put in arbitrary checks to force recompilation). This was just before the short releases started.
- fjh 12y ago> I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. Why would you have to rewrite code because of an expanding std lib?
- Manishearth 12y ago> How long do you (the Rust community) expect Rust to remain backwards-compatible? The hope is for all of 1.*. I forget what the plan is for 2.0, but I think we want to keep things the same (mostly). In practice there will be minor breakages due to unavoidable bugfixes. Expanding the stdlib will never break your code. All changes now are being made with backcompat in mind; older code should never have to update.
- mook 12y ago> The hope is for all of 1.. I forget what the plan is for 2.0, but I think we want to keep things the same (mostly). Right, but how long is that 1.? 2.0 is a good time to have (hopefully small) backwards compatibility breaks, so having a rough idea of an order of magnitude of the timespan would be helpful. > Expanding the stdlib will never break your code. But having it obsolete the non-standard libraries (from e.g. crates.io) will. Code is, unfortunately, not static; things suffer from bitrot, as the toolchain etc. changes.
- tshepang 12y agoNo one knows, and I don't think there's been (a public) discussion about it by projects leads. The only guarantee is that 1.x will not break anything (according to some definition of "break"). There needs to be more experience with widespread use and multiple releases, to see how far that backcompat can be held. Perhaps after 10 releases, it should be a lot more clear whether or not a Rust 2.0 will be needed.
- mook 12y agoThanks; I'm not sure in that case saying 1.x is guaranteed to not break things is very useful at all. Systemd (as far as I know) follows semantic versioning, but their version number is up in the hundreds. Without some sort of guess at how long a release might last, 2.0 might as well ship the minute after 1.0 ships. (Okay, probably not...)
- tshepang 12y agoI don't think systemd does follow any semantic versioning: each of the feature releases change the major version.
- tshepang 12y agoThe core team has reserved the right to break backcompat without changing the major version if they find a serious problem in 1.x series. So I expect that it will be a while (at least a few years) before 2.0 is created.