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, 11:00:58 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
2 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?