Proper wording

Author: anarthal

_posts/2026-04-06-Ruben2026Q1Update.md

@@ -2,26 +2,30 @@
 layout: post
 nav-class: dark
 categories: ruben
-title: "A postgres library for Boost"
+title: "The road to C++20 modules, Capy and Redis"
 author-id: ruben
 author-name: Rubén Pérez Hidalgo
 ---
 
-## The road to `import boost`: a talk in a wonderful conference
+## Modules in using std::cpp 2026
 
-- C++20 modules have been in the standard for 6 years already, but we're not seeing widespread adoption.
-- At the moment, the ecosystem is still getting ready. As a quick example, `import std`, an absolute blessing
-  for compile times, requires build system support, and this is still experimental as of CMake 4.3.1.
-  Just an instance of what it is.
+C++20 modules have been in the standard for 6 years already, but we're not seeing
+widespread adoption. The ecosystem is still getting ready. As a quick example,
+`import std`, an absolute blessing for compile times, requires build system support,
+and this is still experimental as of CMake 4.3.1.
 
-- Something I've realized is that writing module-native applications is really enjoyable. The system is well-thought and allows for better encapsulation,
-  just as you'd write in a modern programming language. (TODO: example).
-- I've been using my Servertech Chat project (a webserver that uses Boost.Asio and companion libraries) to have a taste of what modules really look like in real code.
-  In case you're curious: https://github.com/anarthal/servertech-chat/tree/feature/cxx20-modules
-- When writing this, I saw clearly that having big dependencies that can't be consumed via import is a big problem.
-  With the scheme I used, compile times got 66% worse instead of improving. This is because when writing modules, you tend to have
-  a bigger number of translation units. These are supposed to be much more lightweight, but if you're relying on includes
-  for third-party libraries, they're not!
+And yet, I've realized that writing module-native applications is really enjoyable.
+The system is well-thought and allows for better encapsulation,
+just as you'd write in a modern programming language.
+I've been using my [Servertech Chat project](https://github.com/anarthal/servertech-chat/tree/feature/cxx20-modules)
+(a webserver that uses Boost.Asio and companion libraries) to get a taste
+of what modules really look like in real code.
+
+When writing this, I saw clearly that having big dependencies that can't be consumed
+via `import` is a big problem. With the scheme I used, compile times got 66% worse
+instead of improving. This is because when writing modules, you tend to have
+a bigger number of translation units. These are supposed to be much more lightweight,
+but if you're relying on `#include` for third-party libraries, they're not.
 
 For example:
 
@@ -69,43 +73,47 @@ class redis_client_impl final : public redis_client { /* ... */ };
 
 ```
 
-I analyze this in much more depth in the talk I've had the pleasure to give at using std::cpp this March in Madrid.
-https://youtu.be/hD9JHkt7e2Y for the entire talk.
-
-The TL;DR is that supporting `import boost` natively is very important for any serious usage of Boost in the modules world.
+I analyze this in much more depth in
+[the talk I've had the pleasure to give at using std::cpp](https://youtu.be/hD9JHkt7e2Y)
+this March in Madrid. The TL;DR is that supporting `import boost` natively
+is very important for any serious usage of Boost in the modules world.
 
 ## `import boost` is upon us
 
 As you may know, I prefer doing to saying, and I've been writing a prototype to support
 `import boost` natively while keeping today's header code as is. This prototype has
 seen substantial advancements during these months.
 
-I've developed a systematic approach for modularization, which I summarize here: https://github.com/anarthal/boost-cmake/blob/feature/cxx20-modules/modules.md.
-We've settled for the ABI-breaking style, with compatibility headers.
-I've added support for the remaining compiler, gcc, to the core libraries that we used to support (Config, Mp11, Core, Assert, ThrowException, Charconv).
-And I've added modular bindings for (variant2, compat, endian, system, type_traits, optional, container_hash, io and asio).
-These are only tested under clang yet - it's part of a discovery process. Idea is modularizing the flagship libraries
+I've developed a [systematic approach for modularization](https://github.com/anarthal/boost-cmake/blob/feature/cxx20-modules/modules.md),
+and we've settled for the ABI-breaking style, with compatibility headers.
+I've added support for GCC (the remaining compiler) to the core libraries
+that we already supported (Config, Mp11, Core, Assert, ThrowException, Charconv),
+and I've added modular bindings for Variant2, Compat, Endian, System, TypeTraits,
+Optional, ContainerHash, IO and Asio.
+These are only tested under Clang yet - it's part of a discovery process.
+The idea is modularizing the flagship libraries
 to verify that the approach works, and to measure compile time improvements.
 
-Still lots to do before things become functional. I've received helpful feedback from many community
-members.
+There is still a lot to do before things become functional.
+I've received helpful feedback from many community members, which has been invaluable.
 
 ## Redis meets Capy
 
 If you're a user of Boost.Asio and coroutines, you probably know that there's a new player
 in town - Capy and Corosio. They're a coroutines-native Asio replacement which promise
-a range of benefits, from improved expressiveness, saner compile times, without performance loss.
+a range of benefits, from improved expressiveness to saner compile times,
+without performance loss.
 
 Since I maintain Boost.MySQL and co-maintain Boost.Redis, I know the pain of writing
 operations using the universal Asio model. Lifetime management is difficult to follow,
-testing is complex, things must be remained header-only (and usually heavily templatized).
+testing is complex, and things must remain header-only (and usually heavily templatized).
 Coroutine code is much simpler to write and understand, and it's what I use whenever I can.
 So obviously I'm interested in this project.
 
 My long-term idea is creating a v2 version of MySQL and Redis that exposes a Capy/Corosio
 interface. As a proof-of-concept, I migrated Boost.Redis and some of its tests.
-Still some polishment needed, but - it works!
-You can see the full report: https://lists.boost.org/archives/list/boost@lists.boost.org/thread/FSX5H3MDQSLO3VZFEOUINUZPYQFCIASB/
+Still some polishing needed, but - it works!
+You can read the [full report on the Boost mailing list](https://lists.boost.org/archives/list/boost@lists.boost.org/thread/FSX5H3MDQSLO3VZFEOUINUZPYQFCIASB/).
 
 Some sample code as an appetizer:
 
@@ -141,7 +149,7 @@ capy::task<void> co_main()
 
 ```
 
-## Redis PubSub
+## Redis PubSub improvements
 
 Working with PubSub messages in Boost.Redis has always been more involved than in other libraries.
 For example, we support transparent reconnection, but (before 1.91), the user had to explicitly
@@ -158,9 +166,9 @@ while (conn->will_reconnect()) {
 }
 ```
 
-Boost 1.91 has added pubsub state restoration. A fancy name but an easy feature.
-Established subscriptions are recorded. When a reconnection happens,
-the subscription is re-established:
+Boost 1.91 has added PubSub state restoration. A fancy name but an easy feature:
+established subscriptions are recorded, and when a reconnection happens,
+the subscription is re-established automatically:
 
 ```cpp
 // Subscribe to the channel 'mychannel'. If a re-connection happens,
@@ -171,14 +179,14 @@ co_await conn->async_exec(req);
 ```
 
 Boost 1.91 also adds `flat_tree`, a specialized container for Redis messages
-with an emphasis in memory-reuse, performance and usability.
-This container is specially appropriate for using when dealing with PubSub.
+with an emphasis on memory-reuse, performance and usability.
+This container is especially appropriate when dealing with PubSub.
 We've also added `connection::async_receive2()`, a higher-performance
 replacement for `connection::async_receive()` that consumes messages in batches,
 rather than one-by-one, eliminating re-scheduling overhead.
 And `push_parser`, a view to transform raw RESP3 nodes into user-friendly structures.
 
-With these improvements, code goes from
+With these improvements, code goes from:
 
 ```cpp
 // Loop while reconnection is enabled