Hacker News Reader

Comment by otachack | Hacker News Reader

Congrats! I've fallen off Rust due to pivoting at work plus trying other languages but I'm intrigued again by Tokio's announcement. I'll be trying out your tutorial soon!

View on HN

what did you pivot to and why, if you don't mind me asking?

Can't speak for the commenter, but I used to work for a team couple years ago that used rust and tokio extensively, and some projects were just not a good fit. At the time, futures were well fleshed out but the community hadn't caught up, so we were lacking a futures-compatible postgres and redis client. We wrote the redis client ourselves, and for the main project using rust that was sufficient. But for postgres, that was a show stopper for any other projects we were working on. So we ended up deciding between typescript and go for those.

Just curious, did you consider wrapping the existing sync clients with something like spawn_blocking[1]? If so, what tradeoffs did you find?

[1]: https://docs.rs/tokio/1.0.0/tokio/task/fn.spawn_blocking.htm...

The ecosystem has moved forward a lot since then. Pretty much all IO libraries provide an asynchronous API now.

Note: now tokio-postgres works fine.

Your comment was "dead", but I see nothing wrong with it and vouched for it. This is a valid question asked earnestly.

I'd honestly like to know too.

The tokio tutorial is good, but it needs an example of spinning off multiple (2-3 or more) tasks which run forever. I ended up using spawn() multiple times and having the main thread just sleep in a loop and not using #[tokio::main] because I couldn't figure it out.

You can await std::future::pending, or you can just await the Join Handles returned by the calls to spawn.

Thanks for the tip!

Reply on news.ycombinator.com