yalantinglibs grades itself on two compiler generations at once

The library set is defined by compiler generation, not by topic

The readme's most useful paragraph is the compiler requirements one, because it tells you the collection is deliberately tiered. If your compiler does not support the current standard, only the serialisation libraries compile, and those are named individually: the binary serialiser, and three text ones for JSON, XML and YAML, plus the logger. On a current compiler, everything compiles, which adds the coroutine-based RPC framework, the coroutine I/O layer, the HTTP client, the networking library, the coroutine async framework, the compile-time reflection component and the protocol-buffer codec. So a project on an older standard is not locked out; it gets a coherent subset that happens to be the part that does not need coroutines. That is a good design for adoption because a C++ team with mixed toolchains can still standardise on one dependency. The version floors follow the same logic, with an older set for the subset and a newer set for everything, and there is a CMake option to force either mode. The practical consequence for a reader is that the library list in the description overstates what you get on an older compiler, so the first thing to check is not the model you want but the standard your build system actually sets.

Four installation routes, and the manual one is the honest one

Installation is documented four times over, and reading them in order tells you which one the author would pick. A package manager for the platform is first, then the cross-platform package manager, then two CMake routes, and finally a manual one. The first two are one command each:

brew install yalantinglibs

./vcpkg install yalantinglibs

The two package manager routes are one command each followed by two lines of CMake to find and link the library. The two CMake routes are the fetch-content mechanism with a repository and tag, and the subdirectory mechanism where you drop the source into your tree. Both end with the same link line and a compile-features line requesting the current standard. The manual route is where the real constraints appear, and it is worth reading even if you will not use it. The library is described as header-only, so the instruction is to copy one include directory into your project. But then come three specific include directories to add, one of them a third-party directory and one a standalone directory, each with a note that you can skip it if you installed through CMake, which means the CMake install is doing more than copying headers. Then two conditional steps: enable the language standard with the right flag for your compiler family, and add link options that differ by compiler, including a threading and dynamic-loading pair and a coroutine feature flag for one specific compiler version. Five steps by hand versus two lines with CMake. That ratio is the argument for using a package manager.

A build from source that expects you to run the tests first

The manual build instructions have an opinion about order that is worth copying into your own habits. You clone, create a build directory, and then the readme says to compile the examples and the tests before anything else, running the build in a debug configuration and then the test runner, and tells you where the resulting executables land. The reason given is that verifying the library works on your toolchain before you depend on it is cheaper than debugging your own code. The alternative is offered immediately: four build options to skip examples, benchmarks, unit tests and benchmark data generation, so a consumer who only wants the library can turn all four off. That is a well-designed build file, because the expensive parts are opt-in rather than something you discover after a ten-minute compile. The test and example executables share an output directory, so once you have built them you have a working reference for what correct usage looks like in every library. The developer loop is then described separately: after installing, you copy or open the examples directory and build that on its own. Two build trees, one for the library and one for trying things, which is a sensible separation for a header-only project.

The RPC library, and what the performance claim actually says

The remote procedure call component gets its own section and it is the most performance-oriented part of the collection. It is described as a coroutine-based, high-performance framework for the current standard, header-only, with a claim of more than 400,000 requests per second per thread in pipeline mode, and a claim that you can write a server and a client in five minutes. Both claims need reading closely. The throughput figure names its mode, which is a good sign, because pipelined request handling and request-per-connection are different measurements and quoting only the first would be misleading. What is missing is the payload size, the hardware, the number of client connections, and whether the figure is client-side or server-side. The quick example is correspondingly short: you write a remote function as an ordinary local function returning a view of a string, then include the library header and register it. The design point is that a remote procedure is a local function that has been registered, so the calling convention does not change and the compiler can inline as usual. The documentation links are a mix, with an English introduction, a Chinese conference talk, a Chinese video recording, and an English API page marked as not yet written. That gap is the most useful signal in the section: the introduction is done and the reference is not.

A build matrix of four platforms, and a repository with three build systems

The top of the readme is a table of four operating systems each with a compiler version and a continuous integration badge: one Linux distribution with two compilers, one macOS version with the vendor compiler, and one Windows server version with the Microsoft compiler. Four rows is a modest matrix for a C++ library, and it is a deliberate one, because each row is a whole toolchain rather than a compiler version. The repository is broader than that. There is a CMake build at the root, a Bazel build file, two Bazel module files, a version file for the tool, a Bazel configuration and a rules file, a CMake module directory, a version-controlled formatting configuration, a notice file for third-party attribution, a coverage script, a scripts directory, a source directory with per-library subdirectories, an include directory that is what you actually consume, a documentation directory and a website directory that holds the hosted documentation site. So the project ships four supported build routes for consumers and three for itself. The include directory carrying a third-party subdirectory is what the manual installation instructions were pointing at, and a single target name for the whole collection is what the two-line CMake snippet links against, which is the same design decision as installing the RPC library and the serialiser together.

Editorial conclusion

Adopt yalantinglibs if you are writing C++ and want serialisation, an RPC layer, an HTTP client and a logger from one family with one include path, since the header-only design means there is no build step in your project and the alternative is four separate dependencies. Do not adopt it for its performance claims without measuring, because the readme's request rate figure for the RPC library comes with no methodology and the benchmarks are in a subdirectory you have to build. Four things to verify. Which compiler generation you are on, because the library set changes with it and the readme gives two different version floors, one for the serialisation subset and a higher one for everything. How you will consume it, because there are four supported routes and the manual one requires three include directories and some compiler-specific link and feature flags. That the RPC performance figure is in pipeline mode, which the readme names, and whether your workload is pipeline-shaped. And whether you want one dependency or four, because the collection is installed as a single target, so taking the RPC library also means taking the serialiser. The licence is Apache-2.0, version 0.6.1 was released on 2026-04-29, and the last push was on 2026-09-21.

Frequently asked questions

Official sources

1. alibaba/yalantinglibs on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases