
Is Rust a good choice for web services? - s_c_r
I&#x27;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&#x27;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 &quot;accepted&quot; dependencies recommended for those tasks and it didn&#x27;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?
======
steveklabnik
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.

~~~
s_c_r
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.

~~~
steveklabnik
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/](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".

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

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

~~~
mooman219
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.

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

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

~~~
s_c_r
Reqwest:
[https://docs.rs/reqwest/0.9.20/reqwest/](https://docs.rs/reqwest/0.9.20/reqwest/)

------
platistocrates
If youre a solo dev, sure, why not?

