futures-rs: ten crates, a workspace no_std crate, and lints switched off with comments

The dependency line is two lines and the MSRV is 1.71

The entire usage section is this:

[dependencies]
futures = "0.3"

The version requirement is the 0.3 line and nothing else, and the readme states that the current futures requires Rust 1.71 or later. So the floor is a compiler version rather than a language edition, which matters when a workspace has to support more than one toolchain: the constraint is 1.71, not whatever edition the crates happen to declare. Three releases are recent, 0.3.32 on 2026-02-15, 0.3.33 on 2026-07-18 and 0.3.34 on 2026-08-11, all on the same 0.3 line, so the version requirement does not change under you when a patch lands. The last push to main was on 2026-11-02 and the repository is not archived. The readme also names the crate the user actually depends on as futures, while the repository itself is futures-rs, which is the source tree rather than the package name.

Dropping default features is what makes no_std possible

There are two ways to depend on the crate and the difference is not cosmetic. The plain line enables default features, and the alternative is:

[dependencies]
futures = { version = "0.3", default-features = false }

The reason given is that futures-rs works without the standard library, such as in bare metal environments, but has a significantly reduced API surface there. That single sentence is the whole no_std story: the crate can be built without std, and what you give up to do so is most of the API. The trade is stated plainly enough that there is no separate feature list to consult, because the feature in question is the default set itself. The readme points at docs.rs and the project website for the details rather than enumerating what survives the switch, so a bare metal port still needs the hosted documentation to find out which combinators remain.

Ten library crates, and three more that exist only to be tested

The workspace member list is longer than the crate count most people picture. The published members are futures, futures-core, futures-channel, futures-executor, futures-io, futures-macro, futures-sink, futures-task, futures-util and futures-test. Three further members are not libraries in the ordinary sense: futures/tests/macro-tests, futures/tests/macro-reexport and futures/tests/no-std. Those last three exist so that proc-macro behaviour, re-export visibility and std-free compilation each get their own compilation target rather than being folded into the main test run. That structure is also what makes the no_std claim testable at all, since a no_std build has to be compiled by something. Two example binaries are workspace members too, at examples/functional and examples/imperative.

One lint is commented out because of the minimum supported Rust version

The workspace lint table sets five rustc lints to warn, including missing_debug_implementations, rust_2018_idioms, single_use_lifetimes and unreachable_pub. One is commented out and carries its reason inline: unsafe_op_in_unsafe_fn is marked to be set at crate level instead, since a particular rust-lang pull request is not available on MSRV. The unexpected_cfgs entry is unusual in that it does not just set a level but declares a check-cfg list containing cfg(futures_sanitizer), so the project names the one custom configuration flag it expects and lets the compiler warn about unknown ones. Being explicit about a single accepted cfg in a crate this size says something about how the rest of the surface is handled.

Seven clippy lints are allowed, each with an issue link

Under the clippy heading the workspace allows seven lints at priority 1, and four of the entries carry a rust-clippy issue URL, under one header comment for the whole block. bool_assert_comparison and declare_interior_mutable_const are the first two, the latter pointing at clippy issue 7665. incompatible_msrv is allowed with a comment calling it buggy because it does not consider cfg, with two links including one issue comment. lint_groups_priority points at 12920, manual_map has no link, manual_range_contains points at 6455, and type_complexity carries none. The header comment calls these buggy or noisy lints. So the suppression list is documented in place and traceable, which is the opposite of a blanket allow, and the incompatible_msrv suppression is worth noting because that lint is exactly the kind that would otherwise flag the 1.71 floor this crate advertises.

Dual licensed, and contributions inherit both

The licensing section is the longest part of the readme after usage, and it does something specific: the crate is licensed under either the Apache License Version 2.0 or the MIT license at your option. Both license files sit at the repository root, LICENSE-APACHE and LICENSE-MIT, so the choice is real rather than nominal. The readme then adds that unless you explicitly state otherwise, any contribution intentionally submitted for inclusion is dual licensed the same way, without additional terms or conditions. That default is worth reading as a contributor. The GitHub repository metadata records Apache-2.0 alone, so a tool that reads only that field sees one half of the pair, while someone choosing a dependency has both options available to them. The repository also carries a CHANGELOG.md and a triagebot.toml at the root, the latter being the configuration for the issue triage automation.

What the readme names, and what it defers to docs.rs

The scope statement is short: the library provides the foundations for asynchronous programming in Rust, including key trait definitions like Stream, as well as utilities like join!, select!, and various futures combinator methods which enable expressive asynchronous control flow. Four things are named, and they are named as capabilities rather than as an API listing. Everything past that goes to hosted documentation, with a documentation link to docs.rs and a website link to the project page, both in the header. There is no feature matrix, no adapter comparison, and no statement about which runtime this crate is meant to pair with, even though the surrounding ecosystem treats that as the first question. So the readme establishes what the crate is for and defers the mechanics, which is a defensible choice for a foundations library whose real documentation is generated from the source.

Editorial conclusion

futures-rs belongs in any Rust codebase doing asynchronous work with language-level async and await, and the readme-sized surface area is not a sign of a small library but of one whose documentation lives on docs.rs and a separate website. Three things are worth checking. Decide whether you want default features, because dropping to default-features = false is what makes the crate usable on bare metal and it removes a significant part of the API. Read the lint block in Cargo.toml before assuming the codebase is lint-clean under your own toolchain, since several clippy lints are allowed at workspace priority 1 with issue links explaining why. And pin the 0.3 line, with a stated minimum of Rust 1.71. A team that only needs an executor for a small script is paying for a workspace of ten crates it will not use.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rust-lang/futures-rs on GitHub