Hi toast27 - You should assume you'll have some additional time here -- no matter what, there's a lot for me to finish processing and I'm open to late feedback. Thx, Jeff On Thu, Jul 2, 2026 at 10:22 PM toast27--- via Boost <boost@lists.boost.org> wrote:
Thank you for inviting me to review these libraries!
Qualifiers: - I haven't really had time to thoroughly review and play around with everything. - I mostly just use boost beast without worrying about asio. - I have very little experience using coroutines.
1. I have two projects that use boost beast with asio+callbacks. I'd probably at least try beast2 for future projects. Capy also seems useful as a library that makes working with C++ coroutines less painful, so it seems more useful than a simple asio alternative. This is also a benefit for helping people like me get familiar with it. It's been super easy for me to forget about asio, not use it even when I know it would be the right tool and then have to relearn things later.
2. Interop with callback-based APIs: In JS there are both promise and callback based APIs and converting between the two of them is easy and something you learn pretty early. Given that C and C++ have decades of callback-based APIs and you can't extern "C" coroutines the same interop is needed in capy. run_async makes it trivial to expose a callback API but using a callback-based API within a capy coroutine is less straightforward. It would be nice to have some examples showing best practices or maybe library utilities that make it easier.
My boost beast server has endpoints which use a callback-api to run dynamically linked (extern "C") user functions which themselves can make asio-based requests through the host using another callback-api.
Beast2/http: Not sure if it's too early to review beast2/http libraries but I like the idea of giving the option for a plug and play express-style router (I've used express for years) but I really like the option of doing routing manually too. I haven't looked into how http/beast2 does routing but I know that the other batteries-included C++ server libraries I tried either prevented me from doing the types of routes I wanted or gave performance worse than doing routing manually or required making super clunky middlewares. Also it would be nice to able to use a different body parser for different requests which afaik isn't possible with the current version of beast and might be too much to ask for.
Footguns and rarely used syntax: Overall the example code seems easy to read through and coroutines make things easy to follow but every so often I'll see something weird I wasn't expecting. The documentation does a good job of explaining things along with the limitations, footguns, etc. but there are a lot of modern C++ features that most developers aren't very familiar with which could cause resistance and a lot of people skip documentation.
3. I haven't read through much of the code but the corosio code looks approachable altho inline documentation is always a nice to have so that I don't have read source code or open my browser.
One painpoint for me me with beast has been that it forcibly rethrows exceptions making fatal exceptions hard to trace in gdb. I have to do `catch throw` and hope none of my dependencies are abusing exceptions. It looks like with capy, corosio doesn't forcibly rethrow exceptions, this is great!
4. I read through the capy documentation and it seems great so far. It does a great job as an intro to coroutines since most people still haven't used them.
5. No, sorry, I can try tomorrow if I get time. 6 & 7. - Add some examples for interop with callback-based APIs and I'd say probably yes for capy. - I haven't looked super carefully at corosio but looking at beast2 I saw "No Configuration Macros" and that sounds like a really big commitment that will probably be broken eventually. Examples look fine tho.
8. I think separating capy and corosio was a good decision that makes them fit better into the catalog of focused boost libraries. It did seem to me that asio was doing too much and that made it less approachable.
9. Interop with existing callback APIs is only thing making me hesitant atm. _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/WMTATBRN...