An Async Rust Library in Disguise

Writing asynchronous code in rust is getting easier and easier. The ecosystem is expanding very fast. While Rust does a great job protecting you from leaked futures or a data races, you still need to be very careful about which async libraries you’re using. Calling blocking code is pretty well understood, but how asynchronous runtimes interoperates can get quirky.

To demonstrate, there was a recent example I came across trying to replace rants with async-nats in my tokio-based application.

The rants library is an unofficial async-first NATS client. It works great! Recently, though, the NATS team added an asynchronous flavor to their official NATS.rs client. I wanted to try replacing rants with their new async-nats library for an application I was working on. The transition from rants to async-nats was fairly smooth for my implementation. I was able to get the code compiling and running relatively quickly. However, I didn’t realize until later how expensive using the async-nats library was for my application at runtime.

For a little more context, the application is a simple RPC server. It receives a protobuf request, performs a few sql queries, and returns a protobuf response. At any given time, there are hundreds of active NATS subscriptions, which makes the async variant of NATS valuable for my application.

The async-nats library is actually a wrapper around their non-async (blocking) nats.rs library. It uses the blocking library spawn synchronous work on a thread pool. By creating hundreds of subscriptions in async-nats I was actually creating hundreds of jobs on blocking’s thread pool. With rants, which is fully async and tokio-based, it can poll hundreds of subscriptions with a single OS thread.

The point I want to leave here is that the runtime cost of switching async libraries was not known to me at development time. It wasn’t until I read through the async-nats code that I realized it’s a async convenience wrapper around blocking code with a self-managed thread pool. While it’s providing a very convenient interface for those of us hoping for a pain-free async ecosystem, it certainly challenges my expectations of what an async prefix should mean. Maybe that’s the Go developer in me jumping out. Maybe it’s because it’s hard to go back to heterogeneous concurrent runtimes within a single application after working in Go. Rust eliminates a set of really hard problems that exist within Go, like data races and leaked go-routines, but you still need to be careful with your runtime.

In the end, I reverted back to rants and the application continues to perform well. I am very bullish on Rust and its asynchronous ecosystem. I champion its growth. Even so, be ye warned, for here be dragons.

Related posts:

Claire seems poised for her moment to have it all. Maybe it was too much to ask for a satisfying end, for closure. Nevertheless, I won’t give her up — it delights my heart to see a woman have it all…

While most crypto industry players have to monitor the development of negative trends and live through a series of events that undermine the trust in blockchain technology, the crisis goes far beyond…

I called this publication copforum because I would like this to be a place where we can have discussions, by way of articles, about the law of our land. What does that mean, exactly? Well, they way…