Is Rust a good choice for web services?
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?
10 comments
[ 4.6 ms ] story [ 35.5 ms ] threadYour 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.
That said, async/await produces stuff that implements std::future::Future. The existing async ecosystem was built around the futures crate. Once std future hits stable in the next release, the Futures crate will release a 0.3 version, which has compatibility stuff between the new futures and futures 0.1, so you can technically bridge between the two worlds.
The benefit is basically "you won't make your users use a bridge between your code and the new stuff".
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).
If you accidentally upload secrets, the FAQ recommends changing the secrets because the crate version isn't going to be removed. You can "yank" a version which discourages people from downloading it, but does not prevent them.