Is Rust a good choice for web services? | Hacker News Reader

Is Rust a good choice for web services?

13 pointss_c_r10 comments

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.

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?

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.

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.

Oh good point about the lock file, hadn't thought about that. Will there be a compelling reason to rewrite stuff using async/await? I get that it will be the right way going forward but curious about the benefits for legacy stuff.

Async/await makes code much nicer. For an example (though this post is old and so is a bit out of date) see here: http://aturon.github.io/tech/2018/04/24/async-borrowing/

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".

Thanks for the link! The async/await code is definitely easier to parse mentally. Look forward to the release.

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.

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).

Crates are immutable once published and cannot be pulled by the user.

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.

Could you please elaborate on problem you are working on? How many rps do you want your service to handle? Thank you

I’m curious, what library do you use to handle the REST requests ?

Reqwest: https://docs.rs/reqwest/0.9.20/reqwest/

If youre a solo dev, sure, why not?

Reply on news.ycombinator.com