I've written a few web microservices in Rust that I otherwise would have written in Go, and really enjoyed the experience. After getting over the initial hump of learning how lifetimes and the borrow checker work, I would say I'm just as productive in Rust as I am in Go. If anything I end up writing fewer lines of code in Rust. The tooling is excellent, and even compilation times have gotten better.<p>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.<p>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?
Go has all of that code in its runtime. Rust does not. Hence, you need to get that code somehow, and packages are how you do that.<p>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.
I think the philosophy of Rust is to have a minimal micro-kernel standard library, allowing developers to choose crates that implement solutions in ways that fit their particular problem space. I like that approach more than a 'one true way' approach.<p>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.<p>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).