I am the author of “Rust Web Development” (Manning) [1] and I am using Rust now at my third job full time for “web development” (which is: for backend services).

What I like about Rust, and where it makes the biggest difference to my previous jobs, is the type system and the compiler.

I am using it currently to build distributed systems, using gRPC, adding GraphQL services etc. So there is enough there to take you started without having to rewrite everything yourself.

The community is great to get answers, even many crates have active GitHub discussions or Discord servers.

Sure, there are differences in axum, actix and others. But to be honest, will this impact your productivity all that much?

For some cases, the tooling could be more mature, but the language itself makes you more productive and you are having more fun with it. I also talk about it on the Software Engineering Radio podcast episode. [2]

So I can’t speak for frontend apps, or if you come from Go etc. But I have fun using it for my side projects, and in my day to day life for 3-4 years now, Rust had a substantial impact on the productivity of teams I am working at.

Rough edges are there, yes. Async is maybe not as easy as in Go, and you have to think about memory management more. But these tradeoffs are worth it for me.

[1]: https://www.manning.com/books/rust-web-development [2]: https://www.se-radio.net/2023/05/se-radio-562-bastian-gruber...

Other languages I've used kind of give you this false sense of security and progress, but then suddenly you're troubleshooting some issue for hours and hours. With Rust, you might be troubleshooting the borrow checker for hours and hours (until you get a good grasp on the language), but once you're "Done", it really feels like it's complete and will run without many issues. It shifts some of the mental work to the left, but you're more often left with a feeling of accomplishment and "finished"-ness (at least in my experience).

There are two problems with using Rust for web servers:

1. The only production-ready Rust web servers require writing async request handlers. Async Rust is not fun.

2. The only good Postgres client library is async: https://crates.io/crates/sqlx

I'm trying to remedy the first problem with https://crates.io/crates/servlin .

Solving the second problem will be another project. I hope someone else does it. There is https://crates.io/crates/diesel but it has the same problem as async Rust: incomprehensible build errors.

Honest question: what is it that you dislike in async rust? I personally find it is pretty straightforward

I also don’t have any real issues with async rust. It would be nice if there were a better functional-style interface than what you can get with FuturesExt, but you just drop to procedural style when you need to and it’s fine.

Yeah the only painpoint I have is that it's awkward to use async inside closures, otherwise, things are pretty smooth IMO.

Yeah i built a house pricing web service in Rust under the Axum framework. It is seriously fast, but in my opinion it a very difficult choice for web if speed is not the essential requirement.

I feel -- at least at my level of Rust competence -- working with the borrow checker becomes a combinatorial puzzle where you're mostly trying to just make the errors go away. Even for my simple service the method signatures get quite rediculous, and the amount of indirection involved required to satisfy the borrow checker is not something I feel would scale well.

I've worked on the server side with Axum and Rocket; both are pretty nice. I love SQLX to write queries that validate at build time, and had quite a blast using Maud to write HTML within Rust code.

I'd say the type system is awesome to help model your problems and make sure invalid states can't be represente

The biggest drawback is big(ish) compile times/feedback loops; I can get it down to around 2s on a project that builds SCSS and bundles assets within Rust, but it (and any other compiled language, really) can't beat the fast iterations interpreted languages give you.

I'd definitively recommend it, though! I think the frameworks are pretty nice, do keep in mind they are all more like microframeworks (think flask, not django). If you like writing Rust code and building your own scaffolding is not something you hate, definitively try it out!

We're experimenting with axum with sqlx as a replacement of python's fastapi. First thing we noticed so far: less runtime errors (0) and a huuge improvement in memory usage.

I use Rust for embedded devices and making standalone PC apps. I don't use it for web because there are no frameworks or ORMs on the level of Django. Also, the libs seems to be built around Async for web code, which I don't like.

I love Rust as a language, and its built-in tooling. Web dev requires higher-order tooling that isn't currently in a state I'm happy with. So, I can see myself using Rust in the future for web programming once this is fixed.

I do. I am using async-graphql to create various micro-services and then stitches them into a single GraphQL gateway. Unless you are going for a JavaScript-less website, I don't recommend patterns like Actix. It's better to go for a full React stack with your API bundled into a single point (REST or GraphQL). Static elements can be served from a CDN or else.

Another popular example of rust in web development - https://lemmy.ml/

https://github.com/LemmyNet/lemmy

I'm the author of a guide to web development with rust https://rust-on-nails.com/

It gives you an idea of what a full stack in Rust can look like.

Rust is great for a backend service. We love sqlx as something lighter than an ORM but with glorious compile-time query validation. Actix is very fast and fairly easy to use. We are able to handle hundreds of req/s sustained on a single instance with minimal CPU/RAM usage.

If your company has rust knowledge and/or really cares about perf, and there are no major third-party libraries you’d need that are lacking, it’s a great choice I think.

I have not used Rust for the FE side of web dev (eg yew), so I can’t speak to that.