by s_c_r on 10/1/19, 4:13 PM with 10 comments
My main concern is how many dependencies I end up with doing simple stuff like web requests and database queries. I just finished a script that uses reqwest, rust-postgres, and serde which compiles 221 crates! Am I doing something wrong? I used all of the generally "accepted" dependencies recommended for those tasks and it didn't seem like the Rust stdlib had much support for them. Contrast that with a similar app written in Go and the only dependency outside of the standard library that I needed was pq for Postgres.
I realize that Rust guarantees backwards compatibility for compilation, but what if I need to go back a year from now and make a bunch of changes to that script? Am I going to be in dependency hell like I would be in JavaScript? Are there any other compelling reasons to choose Rust over Go specifically for web services?
by steveklabnik on 10/1/19, 4:18 PM
Your lock file should ensure that the exact same versions of everything are used a year from now. So it should work with no hell. That being said, with async/await five weeks away, the ecosystem is about to get a massive upgrade, and so you will be behind unless you built this all with the pre-release versions of stuff. That said, unless you’re doing active development on the project, that shouldn’t matter, and if you are, you can schedule some time to do the upgrade, like anything else.
by Communitivity on 10/1/19, 5:55 PM
Both approaches have their advantages and crates approach can lead to things like the left-pad problem experience, where the loss of a single one-function package in the NodeJS ecosystem resulted in thousands of projects breaking, including NodeJS itself and Babel.
All in all though, I still like the crate approach. The trick is for developers to not publish trivial crates, and to not allow unpublishing except in extreme circumstances (i.e., for cybersecurity reasons).
by vpEfljFL on 10/2/19, 5:08 PM
by therockhead on 10/1/19, 10:08 PM
by platistocrates on 10/1/19, 9:51 PM