STstouset·Aug 9, 2023
The third-party crate which is not part of the language? https://github.com/async-rs/async-std
In Go 1.21 Releasedasync-rs
async-std
Rust2019–2023
async-rs / async-std
async-std
Async version of the Rust standard library
8Distinct people
10Mentions
0Explicit recommenders
4.1KGitHub stars
What to know before exploring
What it is
Async version of the Rust standard library
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:24:10 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2019-08-16 21:30:39 UTC to 2023-08-09 19:08:04 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
10 sourcesIt is a delicate balance--having a smaller high quality standard library versus the "everything you could possibly need", "kitchen sink" approach found in the Python standard library.
It is great that there is an active Rust community with tons of useful crates, but it can be daunting as a newcomer or when introducing Rust into an organization to discover and adopt the "right" crate(s) for common tasks that the standard library has no answer for.
An example common task is asynchronous programming. For my current project, I am better off using thread::spawn, async / await, async-std, tokio, smol-rs, or something else? I had tentatively selected async-std, but then I came across this thread: https://github.com/async-rs/async-std/issues/992#issuecommen...
If I select a given crate today for a given common task, will the crate still be aro
Read the rest
und and maintained in three years? Will I need to rewrite my project to use the latest crate du jour?
I wonder if it would be possible for the Rust community to design / define a common library of traits for common tasks that could be used as "interfaces" (sorry, Java background) that library crates could be implemented against.
This would provide better stability for crate users and help to avoid analysis paralysis and uncertainty when selecting crates for common tasks that the standard library has no answers for.
There could even be multiple libraries of traits grouped by the type of task. This would allow for more natural groupings based on usage (instead of one huge library of traits) and permit independent changes from other defined libraries of traits.
The Ada programming language has a similar idea called "Standard Library Annexes". See the bottom half of http://www.ada-auth.org/standards/22rm/html/RM-TOC.html where the sections start with alphabet letters instead of numbers. There are standard annexes for: "B. Interface to Other Languages", "C. Systems Programming", "D. Real-Time Systems", "E. Distributed Systems", "F. Information Systems", "G. Numerics", and "H. High-Integrity Systems". Ada toolchains do not have to implement all of these annexes to be a standards-compliant Ada toolchain, but it gives those that do a standard interface so that they are more interchangeable, and code written against them does not have to be rewritten.
Rust is wonderful and I want to see it improve.
Is an idea like this feasible? If not, why not?
Let me ask you this. All nonsense aside about like... standard discussion and what not.
Say I write a Rust program to use `reqwest` to make a HTTP request to some API that is going to return me JSON.
I can compile it to... ELF with Rust I guess on Linux, or I can use Rust to compile it to:
> wasm32-wasi - when using wasmtime this is likely what you'll be using. The WASI target is integrated into the standard library and is intended on producing standalone binaries.
> wasm32-unknown-unknown - this target, like the WASI one, is focused on producing single .wasm binaries. The standard library, however, is largely stubbed out since the "unknown" part of the target means libstd can't assume anything. This means that while binaries will likely work in wasmtime, common conveniences like println! or panic! won't work.
> wasm32-unknown-emscripten
Read the rest
- this target is intended to work in a web browser and produces a .wasm file coupled with a *.js file, and it is not compatible with wasmtime.
Say the Tokio async runtime works for wasm32-wasi (I don't think it does currently, I could be wrong) and reqwest + all of its network dependencies compile to wasm32-wasi (not sure if they do, I think there is progress) and say lite-json or some kind of JSON de-serizaliation works
Why would I compile + run as wasm32-wasi instead of stable-x86_64-unknown-linux-gnu?
Interesting links:
https://github.com/tokio-rs/tokio/issues/4827 - tokio support
https://github.com/async-rs/async-std/issues/505 - async-std support
https://www.reddit.com/r/rust/comments/h9bakg/could_not_find... - > There's no blocking implementation available for WASM. The WASM backend uses HTML APIs (fetch) and is supposed to run in a browser, where you can't block the event loop
Nothing so fancy.
Each worker thread runs in a loop executing a queue of jobs. On every iteration it sets an atomic progress flag to true.
The runtime in which it's contained polls its workers every 1-10ms, atomically swapping in false and checking to see if the previous value was also false - if so, it steals its task queue and spins up another worker to execute it.
https://github.com/async-rs/async-std/blob/ceba324bef9641d61...
In Comparison of Rust async and Linux thread context switch time and memory useif I understand correctly, smol was created by the async-std folks, and async-std now uses it as its runtime
https://github.com/async-rs/async-std/pull/757
In Tokio 1.0 – async runtime for Rust> There's at least one other popular one of note.
The other popular runtimes are async-std [0] and smol [1].
[0]: https://github.com/async-rs/async-std
[1]: https://github.com/smol-rs/smol
In Tokio 1.0 – async runtime for Rustasync-std [0] is pretty widely used as well.
[0]: https://github.com/async-rs/async-std
Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.
In Tokio 1.0 – async runtime for RustI though it had been merged but it looks like they remove the auto blocking detection and merge a revised version of the runtime [1].
1: https://github.com/async-rs/async-std/pull/733
In Writing Rust the Elixir WayI must be dumb, because every time I dive into async/await, I feel like I reach an epiphany about how it works, and how to use it. Then a week later I read about it again and totally lost all understanding.
What do I gain if I have code like this [0], which has a bunch of `.await?` in sequence?
I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are `.await`-ing to complete?
I know this allows the executor to go poll other futures. But if we haven't explicitly spawned more futures concurrently, via something like task::spawn() or thread::spawn(), then there's nothing else the cpu can possible do in our process?
[0] https://github.com/async-rs/async-std/blob/master/examples/t...
In Async-std: an async port of the Rust standard libraryNote that the implementation of the runtime itself is subject to change. It's currently an unbounded threadpool.
https://github.com/async-rs/async-std/pulls?utf8=%E2%9C%93&q...
In Async-std: an async port of the Rust standard library