rust-lang

futures-rs

Rust2016–2022

rust-lang / futures-rs

futures-rs

Zero-cost asynchronous programming in Rust

Systems & Infrastructure

Explore on GitHub Read Hacker News discussions

13Distinct people

15Mentions

0Explicit recommenders

5.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Zero-cost asynchronous programming in Rust

GitHub

Where it is used

No documented product use was verified in the last source check.

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, 3:56:07 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 year15 dated mentions

Observed mentions: 2016-08-10 13:10:57 UTC to 2022-01-13 21:38:49 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

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	6	1	5
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	4	0	4
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	0	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	3	0	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	0	1

What Hacker News says

15 sources

carllerche·Jan 13, 2022

Here is the PR: https://github.com/rust-lang/futures-rs/pull/2551 Yield = wake the `waker_ref`. Avoiding the yield would be clone().wake(). That said, "poll immediately" isn't actually a thing nor was it ever a thing except in incorrect implementations.

In Async Rust in Practice: Performance, Pitfalls, Profiling

fnord123·Dec 29, 2019

https://github.com/rxRust/rxRust Many Rust projects are blah-rs where the rs is dropped in the crate name. So it would be normal to be confused and think Rx == RxRust. e.g. https://github.com/rust-lang/futures-rs has crate name "futures". >There's not that many good, short names. There'd be loads if the Rust community (or.. the 'rust parliamentary community' (people who actually get involved in the RFC processes and see things through to the end (heroes, imo)) (cf PLP[0])) elected to use namespaces for crates. [0] https://en.wikipedia.org/wiki/Parliamentary_Labour_Party

In Rx v0.3 Released, a modern and minimalist pixel editor in Rust

carllerche·Oct 14, 2019

Ah, all the helpers around the "FSM" aspect of things are already exposed as part of the `futures` crate: https://github.com/rust-lang-nursery/futures-rs/

In Making the Tokio scheduler 10x faster

Matthias247·May 7, 2019

It will be interesting to see whether Rusts async ecosystem gets support for it. However there is a little bit of a challenge in the form of an impedance mismatch: Rust Futures and thereby also async functions require that an operation is cancellable at any point of time (by dropping the respective Future). IO completion based systems (like io_uring and IOCP) typically don't support this. If the operation in the Rust userspace would be cancelled while the Kernel proceeds with the operation the Kernel would act on invalid memory. There are some workarounds for this, like wrapping the APIs in ones that only used owned buffers that are passed for the whole duration of the operation and reference-counting the IO objects (file descriptors). But the behavior is pretty tricky. [1] describes the problem. [1] https://github.com/rust-lang-nursery/f

Read the rest

utures-rs/issues/1278

In Efficient IO with io_uring [pdf]

josephg·Nov 28, 2018

> once async/await lands, I think I'll be much happier The current futures proposal is on track for stabilization[1]. You can use futures with async/await today in nightly, and what you use will probably be exactly what lands in stable soon. The biggest missing piece is documentation, but thats starting to improve. My go-to for examples is the futures test suite[2]. And if you want more features, futures-preview 0.3alpha adds a bunch of useful future combinators[3]. futures-preview now just wraps nightly's std::future, which is very nice. Except for the missing documentation, rust's futures are looking great. You can have a play today if you feel keen to jump in. But, as you said it will take some time for the web development ecosystem to mature around the futures API. [1] https://github.com/rust-lang/rfcs/pull/2592 [2] https://github.com

Read the rest

/rust-lang-nursery/futures-rs/blob/master/... [3] https://crates.io/crates/futures-preview/0.3.0-alpha.10

In Rust 2018 survey results

shepmaster·Apr 13, 2017

I've been curious to see how something like tokio[1] and futures[2] would work on a microcontroller. These both seem like good fits for event-based work. [1]: https://tokio.rs/ [2]: https://github.com/alexcrichton/futures-rs

In Ownership is Theft: Experiences Building an Embedded OS in Rust (2015) [pdf]

fooyc·Jan 15, 2017

You are side-stepping the question by explaining how scheduling works. You can not say that there is NO overhead. Using async code in a synchronous fashion is not going to be as fast as using plain sync code. Look at the wait() function: https://github.com/alexcrichton/futures-rs/blob/master/src/f... All this code IS overhead that wouldn't exist if the code was synchronous in the first place.

In Announcing Tokio 0.1

pimeys·Jan 12, 2017

Well, here's the actual wait method: https://github.com/alexcrichton/futures-rs/blob/master/src/f... Of course depending on your executor, the IO can be async or sync.

In Announcing Tokio 0.1

ekidd·Jan 8, 2017

I think some of issue here is that when you ask for "concurrency / parallel programming primitives", you're actually talking about more than one problem. We can divide things up as follows: - Data parallelism. This is where you have (for example) a giant array of data to process and want to use as many cores as possible. For this, rayon is gorgeous: https://github.com/nikomatsakis/rayon Seriously, I can just not say enough good things about programming with rayon, and how nice Rust's "no mutable aliasing" makes coding. Also at some point, Rust will also need good libraries for talking to the GPU. - I/O concurrency. This is where you have a server that needs to respond quickly to 10,000+ sockets, for example. For this, it looks like everyone is standardizing on futures and tokio: https://github.com/alexcrichton/futures-rs https://github.co

Read the rest

m/tokio-rs/tokio But it seems like you're most interested in Erlang-style actors with M:N green threads? The issue here is that—as best I remember the history of Rust—the Rust maintainers decided that green threads were simply too high a level of abstraction for Rust. I think Rust will eventually move back in that direction, first using futures+tokio+async I/O, and then by eventually adding async/await sugar on top. That way, you'll only pay for coroutines/green threads when you explicitly opt in. But it will take a year or so for all this to start maturing, I think. In the meantime, tokio's method-chaining syntax should actually be somewhat tolerable, especially because Rust has a `#[must_use]` attribute that prevents you from forgetting to use a future. If you're lazy, just run everything through rustfmt to get the indentation right.

In The Piston image library is now pure Rust

shmerl·Nov 16, 2016

I meant this one which I saw mentioned recently: https://github.com/alexcrichton/futures-rs

In Rust and the Future of Systems Programming [video]

steveklabnik·Aug 13, 2016

https://github.com/alexcrichton/futures-rs/tree/master/futur...

In Zero-cost futures in Rust

steveklabnik·Aug 11, 2016

> no sane way to intermix them. My understanding is, the idea is to put the blocking stuff in a threadpool with https://github.com/alexcrichton/futures-rs/tree/master/futur...

In Zero-cost futures in Rust

tomdale·Aug 11, 2016

The recent flurry of activity around async IO in Rust has been really exciting; to me, it indicates that the core team's decision to stabilize the language was a smart bet that is paying off in rapid ecosystem growth. One quibble I have with this post is that it talks about futures as a zero-cost abstraction. That might be true (or close to true) from a performance perspective, but in my (admittedly inexperienced) opinion, it seems to have a significant ergonomic cost that is not accounted for. While futures help us deal with multi-threaded coordination of data from multiple sources, that overhead isn't necessary for situations where you're running in a single thread dedicated to doing IO operations. Dealing with futures in your code is not non-trivial. Browsing through the futures version of the HTTP server, I had a hard time following a

Read the rest

long: https://github.com/alexcrichton/futures-rs/blob/master/futur... And it requires a bunch of helper code to go with it: https://github.com/alexcrichton/futures-rs/blob/master/futur... The blog post mentions Tokio, another high-level abstraction on top of mio (by the same author). Because it doesn't require the futures abstraction from top-to-bottom, it offers similar (maybe even a little better) performance with what, to my eyes, is far simpler code: https://github.com/tokio-rs/tokio-minihttp/blob/master/src/l... I'm still learning Rust and spend most of my time in JavaScript. The analogy I'd use is: imagine if in the Node programming model, every API required you to use JS Promises, even at the very lowest level. Even if you could reduce the cost of creating new Promise objects, interacting with them over simple values could make the code you write more verbose. In Rust, that problem is exacerbated by the much stricter type system and the fact that you have to do cross-thread coordination. I'm a total beginner to systems programming, and a lot of this stuff is above my pay grade. However this shakes out in the community, I'm very happy to see Rust on the way to becoming the fastest, most productive way to write high-performance web services.

In Zero-cost futures in Rust

bascule·Aug 11, 2016

While the benchmarks are looking a lot better than many other similar Rust libraries in this space, I'm not sure the code is in a state where they're actually meaningful yet: https://github.com/alexcrichton/futures-rs/blob/master/futur...

In Zero-cost futures in Rust

rkangel·Aug 10, 2016Submission

Getting started with Futures [Rust]

2 points · Open discussion