Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> I'm willing to bet a lot of people start using Rust for backend web development.

It will happen, but it's not something you should do today. The async ecosystem in Rust is not yet ready for prime time, there are key language and stdlib features that are just missing. And this in turn holds the web ecosystem back. If you write a web backend in Rust today, you might just do a lot of pointless work that you'll have to rewrite in the future anyway as more advanced frameworks come along and the earlier ones are practically abandoned.

View on HN

My company runs everything on AWS lambda, I’ve worked on Lambda with Go, Python and Typescript before this, Rust is by far the best experience I’ve had. Async works great, it’s definitely a lot harder to figure out the ecosystem than something like Go, but there’s nothing missing that I know of?

async does not work great, maybe for simple poc but once you start diging it's not well done. The debugging part is even worse.

My best two takeaways for using AWS lambda:

1. Use Rust 2. Use containers

I save a lot of time with those two decisions. My lambdas are significantly less likely to have runtime errors. And with containers I can select which version to run from my registry

What are you talking about? Async is marvelous in its current state. It's not changing much at all.

I had to port async runtime APIs many moons ago and it was an easy migration. Now things are baked in and I haven't had to change anything for years.

> there are key language and stdlib features that are just missing.

Like what?

> If you write a web backend in Rust today, you might just do a lot of pointless work that you'll have to rewrite in the future anyway as more advanced frameworks come along and the earlier ones are practically abandoned.

1. If you write atop Tokio, you're fine. (You wouldn't pick anything else unless you have special case needs for your app.)

2. If you write atop Actix/Axum(Tokio), you're doubly fine -- they're abstracting away everything.

Take a look at https://rust-lang.github.io/wg-async/vision.html for the shiny things that are planned in future versions of Rust. This will most likely require brand-new frameworks and create a whole lot of pointless churn for pre-existing code.

> This will most likely require brand-new frameworks and create a whole lot of pointless churn for pre-existing code.

I doubt it. I suspect existing code will continue to work with minor mechanical changes, and the improvements will just open up new use cases that are either impossible or awkward to do today.

In the list of projects I don't see many that would actually materially change frameworks, beyond changes from -> Box<dyn Future> to -> impl Future or reduced boilerplate due to more concise syntax sugar.

https://rust-lang.github.io/wg-async/vision/roadmap.html

So don't use async. You can get a very, very long way with threads and good old fashioned blocking I/O.

Except that in practice every Rust I/O framework uses async these days. You can't really avoid it.

Reply on news.ycombinator.com