Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

I agree. I've been writing a lot of javascript for the past few years. I've come to love async in javascript - async makes my javascript code fast, readable and reliable.

Moving to rust, a lot of the struggle I've experienced has come from trying to write rust the way I would javascript - by using rust's async primitives. Async support in rust is complex, immature and incomplete. And its been this way for years.

For a project a few years ago, I tried making an HTTP server which supported a custom SSE-style endpoint. The resulting code was atrocious - it was long, complicated, and I needed to invoke deep lifetime magic that I still don't fully understand to make it compile. I just want to implement both sides of an async stream - but no; thats apparently too hard. I got hundreds of lines in, and the code still wasn't finished. I rewrote it in about 20 lines of javascript and it works great.

I've decided to stay away from async rust until the language & ecosystem mature. Synchronous rust is a delight. I'm going to need to do more IO soon, and I'm dreading it. I don't really want to use threads, but I think it might be the right choice given the current state of async rust.

Maybe I just got lucky, but I just built an http to irc relay using Rocket (tokio based) and the irc client crate (also tokio based) and the implementation came out super clean. I made some small wrong turns along the way like breaking graceful shutdown by putting a non terminating future into a join! with the main Rocket future, but with enough time in the various docs I got it right and it's pretty elegant. The Anyhow crate made error handling easy, and I'm happy to see Rocket building on stable since last time I used it. There wasn't really any borrow checker pain or messing with lifetimes. The compiler was very helpful, as usual.

Lunatic (https://docs.rs/lunatic/0.7.0/lunatic/) is an Erlang inspired alternative to async rust and manual threads.

Does anyone know what the final state of Rust’s async will look like? It seems like everyone is dreading it now but will it ever get to a point that people like writing it?

async is final unfortunately. My experience with rust so far is that there is a small set of program structures which Rusts type system works well for, and a large set of programs and structures where it becomes an unholy mess to make work e.g. deep lifetime magic, complex async/traits scope, etc.

If you stick on the golden path then the compiler has your back, deviate, and then you are stuck in a deep hell of compiler suggestions that don't pan out. One observation I've had is that complex lifetime problems are usually solved by copy's or the use of unsafe in most production code. I would love to see a future equivalent of "clean code" for Rust, as the current situation is reminiscent of early java programming.

Async is final, and I think the design is fine.

The problem is that async code doesn't interact properly with the rest of the rust language. You can't make async traits, async iterators or streams, or use async closures. The problem isn't async. Its that the rest of the language is apparently (still!) incompatible with async code.

All of this stuff is "coming" - and by that I mean, there have been RFCs kicking around since 2017 aiming to fix these problems. Blergh.

Eg:

GATs: https://github.com/rust-lang/rust/issues/44265 (This one might land soon!)

Async closures: https://github.com/rust-lang/rust/issues/62290 (seems to have stalled)

TAIT: https://github.com/rust-lang/rust/issues/63063 (seems to have stalled)

And so on.

> async is final unfortunately

This is wrong. Async traits and iterators will be huge improvements to the language, and there is more in progress.

Can you provide examples of copy/unsafe being required for complex problems?

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

In my experience I quite enjoyed async Rust, there was definitely quite a bit of yak shaving required to get tokio and various other async/sync libraries to play nicely together, but once that was done I haven't run into any significant issues with it. Are there problems with it I'm unaware of or is the somewhat fractured async ecosystem still a too high barrier to entry?

I agree. It's not like there aren't plenty of improvements to be made, but I write a lot of async Rust and the limitations (which are well enumerated elsewhere in the comments) just aren't really an issue for what I do.

The first step of any Rust project is to decide if you really need to use Rust.

If you control the hardware, then you need to compare the dollar cost of using a GC language and just throwing more hardware at the problem, vs the dollar cost of using Rust and throwing more developer time at the problem.

Reply on news.ycombinator.com