Rust has pretty strong stability guarantees. Backwards incompatible changes are only made using “editions” where every compiler version supports all previous editions and editions are fully interoperable.
The versions still make me reluctant to try rust. I’m sure it’s reliable in theory but I’m always getting cockblocked when someone’s python project doesn’t work because of dependencies and different versions. I once remade a python 3d object format converter in c++ because that was easier than a) fixing whatever dependency and runtime version shenanigans or b) using whatever bullshit ass Windows-only propriety software most people used to make that file conversion
I use both python and rust extensively and they are literally day and night when it comes to dependency issues. The only problems I’ve ever had with rust are when there is a non-rust dependency that’s not cross platform (which would be a problem in c as well). The editions (which are different from versions) are nothing to be afraid of either, iirc a rust 2021 project can depend on 2018 and 2015 libraries without issues.
rust doesn’t install dependencies globally, and packages or versions can’t be deleted from crates.io (they are instead yanked which prevents them from being used in new projects, while throwing a warning in existing ones)
rust editions are fully compatible with each other so you can use 2015 crate in a 2021 project and vise versa.
rust also allows having multiple versions of dependencies at the same time.
if crate A depends on B 0.1 and crate C depends on B 0.2, rust will download and use both versions of B.
you can run into issues if:
…you’re using c dependencies
…you have incompatible crate versions; cargo treats different versions as completely separate crates (please note that this is not a big issue, this shouldn’t scare you off; for example if there’s a crate A that depends on crate B0.1 and provides fnA::dostuff(B::TypeFromB) and you have A and B0.2 specified as dependencies, you won’t be able to use your B::TypeFromB as an argument in A::dostuff(...), and you’ll have to downgrade your version of B to 0.1 or ask the crate developer to update their library)
…you have a multi-crate cargo workspace or monorepo and forgot to specify resolver="2" (it uses resolver="1" by default for compatability, which is incompatible with a lot of crates)
Also, you can just download an older version of the toolchain and use that to compile the project. If the project is properly setup it’ll tell you the toolchain version it used. If not you can probably guess by the time of the last commit ^^
Rust has pretty strong stability guarantees. Backwards incompatible changes are only made using “editions” where every compiler version supports all previous editions and editions are fully interoperable.
https://doc.rust-lang.org/stable/edition-guide/editions/index.html#what-are-editions
The versions still make me reluctant to try rust. I’m sure it’s reliable in theory but I’m always getting cockblocked when someone’s python project doesn’t work because of dependencies and different versions. I once remade a python 3d object format converter in c++ because that was easier than a) fixing whatever dependency and runtime version shenanigans or b) using whatever bullshit ass Windows-only propriety software most people used to make that file conversion
I use both python and rust extensively and they are literally day and night when it comes to dependency issues. The only problems I’ve ever had with rust are when there is a non-rust dependency that’s not cross platform (which would be a problem in c as well). The editions (which are different from versions) are nothing to be afraid of either, iirc a rust 2021 project can depend on 2018 and 2015 libraries without issues.
rust doesn’t install dependencies globally, and packages or versions can’t be deleted from crates.io (they are instead yanked which prevents them from being used in new projects, while throwing a warning in existing ones)
rust editions are fully compatible with each other so you can use 2015 crate in a 2021 project and vise versa.
rust also allows having multiple versions of dependencies at the same time.
if crate A depends on B 0.1 and crate C depends on B 0.2, rust will download and use both versions of B.
you can run into issues if:
Athat depends on crateB 0.1and providesfn A::dostuff(B::TypeFromB)and you haveAandB 0.2specified as dependencies, you won’t be able to use yourB::TypeFromBas an argument inA::dostuff(...), and you’ll have to downgrade your version ofBto 0.1 or ask the crate developer to update their library)resolver="2"(it usesresolver="1"by default for compatability, which is incompatible with a lot of crates)@Rian is correct. the only dependency problems ive had are relating c libraries
Also, you can just download an older version of the toolchain and use that to compile the project. If the project is properly setup it’ll tell you the toolchain version it used. If not you can probably guess by the time of the last commit ^^