Rust Lang

3 readers

1 users here now

Rules [Developing]

Observe our code of conduct

Strive to treat others with respect, patience, kindness, and empathy.
We observe the Rust Project Code of Conduct.
Submissions must be on-topic
Posts must reference Rust or relate to things using Rust. For content that does not, use a text post to explain its relevance.
Post titles should include useful context.
For Rust questions, use the stickied Q&A thread. [TBD]
Arts-and-crafts posts are permitted on weekends.
No meta posts; message the mods instead.

Constructive criticism only

Criticism is encouraged, though it must be constructive, useful and actionable.
If criticizing a project on GitHub, you may not link directly to the project’s issue tracker. Please create a read-only mirror and link that instead.
Keep things in perspective
A programming language is rarely worth getting worked up over.
No zealotry or fanaticism.
Be charitable in intent. Err on the side of giving others the benefit of the doubt.

No endless relitigation

Avoid re-treading topics that have been long-settled or utterly exhausted.
Avoid bikeshedding.
This is not an official Rust forum, and cannot fulfill feature requests. Use the official venues for that.

No low-effort content

Showing off your new projects is fine

No memes or image macros

Please find other communities to post memes

No NSFW Content

There are many other NSFW communities, let’s keep this related to the language

founded 1 year ago

MODERATORS

admin@lemmyrs.org

erlend_sh@lemmyrs.org

Advantages of async runtimes other than tokio? (lemmy.sdf.org)

submitted 1 year ago by thomask@lemmy.sdf.org to c/rustlang@lemmyrs.org

4 comments fedilink hide all child comments

In the interest of sparking a little discussion (not too spicy please, we're having a nice clean start here) I thought I would ask the question. It's something I'm legitimately wondering about as someone who has reached for tokio by default for years.

I'm aware of async-std and smol, probably unaware of others. If you've used or prefer a different async runtime, what trade-offs might I be interested in or what features am I missing out on?

top 4 comments

sorted by: hot top controversial new old

[–] Aloso@lemmyrs.org 1 points 1 year ago (1 children)

There are executors for more specific use cases.

For example, bastion is a "Highly-available Distributed Fault-tolerant Runtime", inspired by Erlang, and including an async executor.
embassy includes an async executor specifically for embedded systems.
fuchsia-async is an executor for use in the Fuchsia OS.
wasm-bindgen-futures converts Rust Futures to JavaScript Promises and schedules them to run to completion. It could also be seen as a (very basic) executor.

[–] ids1024@lemm.ee 1 points 1 year ago

I think gtk-rs is another interesting example. The glib crate provides an async executor, since glib already requires running its main loop. So if you just need to run a couple futures you don't need another executor in one or more other threads, and tasks spawned in the glib executor can call functions that need to be run in that thread, since gtk types are generally not thread safe.

So integrating into other things could be a reason to use a different executor..

[–] huntrss@feddit.de 1 points 1 year ago

Not so much relevant for production use cases but from an educational point of view: whorl is pretty great. One file that explains async runtime basics from top to bottom. The cleverness of doing this in one source code file is remarkable.

[–] popstarfreas@lemmy.world 1 points 1 year ago

This won't really help you consider another runtime specifically, but it is an instance of not choosing Tokio.

When I was benchmarking with Tokio I found it had quite a difference (higher cpu usage) to other options I was exploring. My specific use-case was an async single-threaded application which does mostly network io + timers. I would be interested to see how Tokio fairs today (I tested it over a year ago) and quite possibly any advice or tips in writing efficient code with it. My benchmark was send/recv with a UDP socket and print out stats in a timer (that's the core idea of what I needed to use it with). Comparing both CPU usage and maximum throughput.

For normal async, I would probably still reach for Tokio, but the use case I was looking at was very much specific to what I was working on at my job (still am), and lower CPU usage as well as higher throughput is what we needed. We ended up building a small internal runtime that uses mio, it was also fun to implement. In the benchmarks we ran, it used less CPU % than Tokio, and achieved higher throughput, by enough that we thought it was worth continuing to use our internal one.