async_simple offers three concurrency models and admits one needs installation

Three models, and the reason for three is compatibility

The description names three component families and the reason to read all three rather than pick one. There is a stackless coroutine built on the C++20 feature, a stackful coroutine, and the traditional future and promise. On its face this looks like a library that has not chosen. In practice it is a compatibility surface, and the reason is visible in the compiler requirements: stackless coroutines need a compiler new enough to have them and debuggable enough to use them, while a stackful coroutine works on any compiler because it manages its own stacks, and futures work everywhere. A codebase that supports four compiler versions cannot standardise on the newest thing. So the library offers a common set of components whose shape is recognisable across all three, and lets a module pick the one its callers can compile. The readme's online playground note reinforces it: you can try the library in a browser compiler explorer, but the stackful coroutine cannot be used there because it requires installation. That is a one-line admission that the three models are not equally portable, and it is the most useful sentence in the quick experience section. The documentation is split the same way, with a separate page for the stackless coroutine component and a getting-started page whose demo counts characters in a file.

The compiler section is the most honest documentation in the project

Read the compiler requirements and you learn more about the project than any feature list would tell you. Three compilers are named with version floors: one Clang, one GCC, one Apple Clang. Then four caveats follow, and each is a maintenance cost stated plainly. With a specific GCC major version you need a flag to suppress an uninitialised-value warning, and the reason given is a false positive in that compiler's diagnostics. With a specific Clang version there may be compiler bugs affecting one of the generator components, and the recommendation is to use a later version. If you hit a specific error code from Microsoft's compiler you should add a flag that changes exception handling behaviour. And the stackful coroutine needs an external I/O library installed, so it is not usable in a browser playground. That last one is the most consequential and the least likely to be noticed. A stackful coroutine library needs an event loop underneath, and this project depends on a standalone version of a well-known standalone networking library, pinned to a specific commit rather than a version tag. Pinning a commit is reproducible and it means nobody gets security fixes by upgrading, which is a deliberate trade a security-conscious user should know about. The readme is upfront about all of this, which is why this section is worth more than the feature description.

Four build systems, and that is a maintenance surface

The top-level listing shows what it costs to support a library across the C++ ecosystem. There is a CMake build, a Bazel workspace file, a module rules file, a Bazel ignore file, a Conan recipe, an xmake script, a separate Bazel directory, a CMake directory, a rules file for C++ modules with Clang, a notice file, and a package manifest for a documentation site. Then the installation instructions match, with a package manager path, a CMake path with a full clone and build and install sequence, a find-based CMake integration, and a manual include-path approach. Two details in the find-based section are the ones that matter to a consumer. First, there are three link targets, one dynamic, one header-only and one static, which is a courtesy most libraries do not extend to a concurrency library and which lets you choose your deployment shape. Second, the manual approach is described as almost header-only, and the exception is named precisely: the stackful coroutine part is not header-only and must be linked. So the header-only claim holds for two of the three models, which is a fact worth holding onto if you are distributing a static binary. The build section also documents several CMake switches for turning tests, benchmarks, demo examples and the asynchronous I/O dependency on or off, and it goes out of its way to explain the benchmark switch's caching behaviour in a reused build directory, which is the level of detail that only appears in a project where people file bugs about it.

Installing with a package manager is one line, and it is the line to use

The shortest path in the readme is a single command from a cross-platform package manager, and it is worth preferring over the build-from-source path for a first evaluation:

./vcpkg install async-simple

The longer path exists for people who need to build it themselves, and it is a proper sequence: clone a single branch at depth one so you do not download the full history, change into the directory, create a build directory, change into it, configure with tests, benchmarks, the demo example and a sanitiser all disabled, build, and install with an optional prefix. The fact that the readme's own install command turns off tests and benchmarks is a small signal about the intended consumer, which is a person who wants the library in their build, not a person who wants to run the project's test suite. The same pattern appears in the develop section, where the two optional dependencies for testing are the kernel asynchronous I/O library and a test framework, both described as optional with testing before use highly suggested. The default behaviour there is to fetch the test framework from version control at build time to ensure the correct version, with an explicit escape hatch for people behind a restrictive network who can point the build at an installed copy. A build that downloads its test dependencies by default is a real consideration in a locked-down build environment, and the readme addresses it rather than leaving you to discover it.

Documentation as a hosted site, and a package manifest for it

Two things about the documentation are worth noting. First, the documents are hosted on a documentation site rather than only in the repository, and the readme links a getting-started page there while also pointing at the source page for the stackless coroutine component and a demo in the repository. That split is normal and sensible: long-form guides in a site, reference material next to the code. Second, and more interesting, the repository root contains a package manifest for a Node-based static site generator, whose description says it is a collection of C++20 libraries including this one, a remote procedure call library and a serialisation library, with the three of them bundled. So this repository is one member of a family, it shares a documentation toolchain with its siblings, and the family is a collection rather than a single product. That tells you something about the maintainers' approach: they build small focused C++20 components and present them together. The repository also carries a Chinese readme alongside the English one, a change log, a debug directory, a docker directory, a demo example directory and a benchmark directory, which is a fairly complete project skeleton. The demo depends on the standalone networking library at a pinned commit, so if you clone and build the demo you inherit that pin, and if you only install the installed library you do not.

Editorial conclusion

Adopt async_simple if you have a C++20 codebase with no async story and want a library that offers a stackless coroutine, a stackful coroutine and a future type from the same project, because the choice is then a per-call-site decision rather than a bet on one model. Do not adopt it if you are on a compiler older than the stated floor or if your build is already standardised on another async library, since the value collapses outside those two cases. Four things to verify. That your compiler is inside the supported range, which names a floor for three compilers and then immediately lists two diagnostic false positives and one compiler bug, so read the whole section rather than the first line. How you will consume it, because the readme says the library is almost header-only but the stackful coroutine part is not, which means a header-only assumption fails for exactly one of the three models. Whether you want the build system complexity, since the top level carries CMake, two Bazel files, a Conan recipe, an xmake script, a C++ modules rule for Clang and a package manifest for a documentation site, which is a lot of ways to build one library. And which release you target, since the tags read 1.2, 1.3 and 1.4 with a mix of prefixed and unprefixed names. The licence is Apache-2.0, version 1.4 was released on 2025-07-29, and the last push was on 2026-09-13.

Frequently asked questions

Official sources

1. alibaba/async_simple on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases