Hacker News Reader

Comment by insanitybit | Hacker News Reader

The same reason as ever. Not everyone wants to use the same runtime.

Sure, but now if my rust application isn't using tokio I have to include it as a new dependency because the author of this lib decided to use it as his async runtime?

I'm not trying to be pedantic, but this split over async runtimes was what originally turned me off of rust years ago and it still seems to be an issue.

I'm using async on esp32 with embassy, for instance, where there's simply no room and no need for a runtime as complex as tokio.

It's not pedantry, you're trying to find something in Rust that's simply not there. If this sort of thing turns you off on Rust you should be looking at a programming language with other priorities.

I’ve had the same reaction. We’ve seen this play out in other language eco-systems (Java - JAXP, javax.validation, JPA, etc all ended up with a de facto single implementation) and the idea of pluggable implementations sounds appealing but rarely pays off. The price that Rust paid for this abstraction - which in fact ended up not being useful as tokio is the only reasonable choice - was high in terms of requiring ugly (to my eyes) changes to its type system.

There is no price to pay on the type system that was imposed by tokio. I assume you're saying something like "I have to add 'static in generics" or something?

It has absolutely paid off, there are many people not using tokio.

Tokio is definitely not the only reasonable choice. I use embassy[1] on microcontrollers (the Pi Pico and ESP32 in my case), where tokio can't run.

[1] https://embassy.dev/

You would only have to include it if the library uses `spawn`, as far as I am aware, or some tokio specific type, which is the same as any other library.

The author of this library can leave the async library choice up to the user.

iced does that quite well.

Because Tokio, while great for lots of things (ie default decent performance with ease of use), is a performance bottleneck if you want extremely high performance.

For example, the best this DB can do is ~3.7Mkeys/s for non durable writes and 162k/s for durable. I have an equivalent DB that’s always durable and does 30M/s* (for 8 byte entries) because it doesn’t use Tokio among other things. For this dataset it would be saturating the disk I/O no problem so I would expect it to be running ~7-14M/s depending on how fast your SSD is (~2-4x faster than non durable mode and 40-80x faster than its “durable”)

* it was running at 70-100mhz at one point but the challenge is keeping the hot path at ~10ns as you add features and other things.

Thank you for a complete answer.

Out of curiosity where do you stand on libraries like this imposing a runtime choice on the user?

Is it standard in the rust ecosystem to have multiple async runtimes in a project?

It’s fine to have multiple runtimes. There’s probably some additional performance overhead at the API boundary because you have to transfer the work to run on the other runtime but I haven’t benchmarked what that looks like. It’s probably on the order of 50ns-1us if done naiively and depending on contention (ie you’re looking at a max throughput of 20M-1M/s).

Use whatever you want. Tokio is a very good work stealing runtime which is what Apple’s GCD popularized 17 years ago. It’s a fine model but sacrifices total throughput for ease of use and “easy” multithreading. Thread per core with pinned cores is what you use when you prioritize throughput and absolute possible latency. Tail latencies can suffer if you make a mistake and have imbalanced work on a single thread

Reply on news.ycombinator.com