DEV Community: Gaspard Kirira

C++ Needs Better Tooling Around the Project, Not Only Around Compilation

Gaspard Kirira — Thu, 09 Jul 2026 21:09:49 +0000

In many C++ projects, the code is not always the hardest part.

The real difficulty often appears around the project itself. A team needs to know where private packages are published, which version was used, which lockfile belongs to which machine, who changed something, why a build failed, and who has access to the workspace.

These details matter because they affect how a project is built, shared, reviewed, and maintained. But in many teams, they are not kept in one clear place. They end up scattered across local machines, CI logs, terminal history, GitHub issues, private folders, and team messages.

At the beginning, this can feel manageable. A small team can remember what changed, which dependency was updated, or why a build failed last week. But as the project grows, memory is no longer enough. The workspace becomes harder to understand, builds become harder to reproduce, and important context becomes easy to lose.

That is the problem Softadastra Cloud is being built to address.

Softadastra Cloud is a C++ cloud workspace for Vix projects, private packages, and build activity. It is designed to give C++ teams a clear place to manage the context that lives around the code.

This includes private package publishing, package versions, lockfiles, build reports, workspace members, access permissions, notifications, and project activity.

The goal is not to replace the developer’s machine. C++ developers should still be able to work locally, control their environment, and build their projects in the way that makes sense for them.

With Vix, the developer keeps control locally. With Softadastra Cloud, the team gets a shared layer for visibility, history, and coordination.

A workspace should make it easier to answer simple but important questions:

What changed?
Which package version is being used?
Which build failed?
Who has access?
What happened while I was away?

Softadastra Cloud is meant to answer these questions without turning the workflow into something heavy or noisy. It should feel simple, serious, and useful for real C++ work.

Not just another dashboard full of buttons. Not just a backend panel. A workspace where a C++ developer can quickly understand the state of a project and know what needs attention.

Softadastra Cloud is still in active development, but the direction is becoming clear.

C++ needs better tooling around the workflow, not only around compilation.

Softadastra Cloud is one step in that direction.

Building my official developer profile around Softadastra and Vix.cpp

Gaspard Kirira — Sun, 05 Jul 2026 23:11:50 +0000

I created a new official profile page for my work:

https://gaspardkirira.softadastra.com

The goal of this page is simple. I wanted one clear place that connects my identity as the founder of Softadastra with the projects I am building, especially Vix.cpp.

Vix.cpp is a modern C++ runtime for building fast and reliable applications. The project started from a problem I kept seeing in C++ development: as projects grow, the difficulty is not only the language itself. The real pressure often comes from project structure, dependencies, builds, modules, diagnostics and the work needed to keep a project reliable across machines and teams.

Softadastra is the company I am building around that direction. Its focus is C++ tooling. The goal is to create practical tools that make serious C++ development easier to organize, maintain and deliver.

This profile page is not meant to be a portfolio full of every small detail. It is meant to be a canonical public page for my work. It explains who I am, what Softadastra is, what Vix.cpp is, and how the current projects fit together.

The site is intentionally simple. It is built with static HTML, CSS and JavaScript. No framework was needed for the first version because the main goal is readability, speed and clarity. Search engines should be able to understand the page easily, and developers should be able to read it without noise.

The current direction around Softadastra is also becoming clearer:

Vix.cpp is the local workflow for C++ applications.
Rix is the unified userland library layer for Vix.cpp.
Softadastra Cloud is the project operations platform for C++ teams using Vix.
Ivi.php is a fast, simple PHP framework for APIs and SPAs.

For Softadastra Cloud, the idea is especially important:

Vix works locally. Softadastra Cloud organizes the team layer.

That means workspaces, private packages, lockfile history, build reports, diagnostics, CI profiles and permissions. The goal is to reduce the operational stress of modern C++ projects, especially when the project becomes bigger than one developer or one machine.

This is still a long journey, but creating this official page is one small step toward making the work easier to understand from the outside.

I will continue improving Vix.cpp, writing more about C++ tooling, and building Softadastra around the problems that matter in real developer workflows.

Official profile:

https://gaspardkirira.softadastra.com

Vix.cpp:

https://github.com/vixcpp/vix

Vix.cpp vs Drogon vs Crow: a local benchmark of the v2.7.0 HTTP runtime

Gaspard Kirira — Tue, 30 Jun 2026 06:41:12 +0000

Vix.cpp vs Drogon vs Crow: a local benchmark of the v2.7.0 HTTP runtime

Vix.cpp v2.7.0 is moving forward, and one of the things I wanted to validate more seriously before pushing this release further was the HTTP runtime.

Vix.cpp is not only a web framework. It is a C++ application platform and developer toolkit around real native C++ projects. The goal is to make C++ development more direct: create a project, run it, build it, test it, install SDK profiles, use modules, package applications, and prepare them for production without losing the native C++ model.

But even if Vix.cpp is broader than a web framework, the HTTP runtime still has to be fast.

So I decided to compare it with two known C++ web frameworks: Drogon and Crow.

Drogon is one of the strongest references in high-performance C++ web development. Crow is also well known because it gives C++ developers a simple and lightweight way to write web services.

That makes this comparison useful.

Not because Vix.cpp is trying to become Drogon or Crow, but because developers need a clear idea of where Vix.cpp stands when the discussion is about C++ HTTP performance.

Website: https://vixcpp.com

The benchmark context

This benchmark was not run on a cloud server.

It was not run on a dedicated bare-metal benchmark machine.

It was run locally on my laptop, the same machine I use for development.

The machine was an HP EliteBook running Linux on x86_64 with 8 CPU threads.

Platform        : linux
Architecture    : x86_64
Kernel version  : 6.17.0-35-generic
Hostname        : softadastra-HP-EliteBook-x360-1030-G3
CPU count       : 8
Page size       : 4096 bytes

That detail matters because the goal of this benchmark was not to claim a universal performance result.

The goal was more practical.

I wanted to see how Vix.cpp behaves on the same machine, with the same benchmark pressure, against two known C++ web frameworks.

Benchmark command

Each framework was tested with a simple endpoint:

/bench

The benchmark command was the same:

wrk -t8 -c800 -d30s --latency http://127.0.0.1:8080/bench

This means:

8 wrk threads
800 concurrent connections
30 seconds duration
latency distribution enabled

The server runtime was also configured around 8 threads where applicable.

This benchmark does not include database access, JSON serialization, authentication, templates, file serving, middleware chains, TLS, or application logic.

It is a simple HTTP runtime benchmark.

That makes it limited, but still useful.

A runtime that wants to support real C++ applications should at least show that it can handle a simple high-concurrency HTTP endpoint correctly.

Drogon result

Drogon was the fastest in raw throughput in this run.

Running 30s test @ http://127.0.0.1:8080/bench
  8 threads and 800 connections

Thread Stats   Avg      Stdev     Max   +/- Stdev
  Latency     6.38ms    4.61ms  94.29ms   72.13%
  Req/Sec    14.51k     3.71k   37.65k    74.49%

Latency Distribution
  50%    5.49ms
  75%    8.64ms
  90%   12.03ms
  99%   21.16ms

3461890 requests in 30.06s, 498.53MB read
Requests/sec: 115151.01
Transfer/sec: 16.58MB

The important number here is:

Drogon: 115,151.01 requests/sec

This is a strong result, and it confirms why Drogon is usually treated as one of the serious references for C++ HTTP performance.

Vix.cpp result

Vix.cpp came very close to Drogon in raw throughput.

Running 30s test @ http://127.0.0.1:8080/bench
  8 threads and 800 connections

Latency:
  Avg:   7.31ms
  Stdev: 16.26ms
  Max:   606.15ms

Latency Distribution:
  50%:  6.51ms
  75%:  7.59ms
  90%:  8.73ms
  99%: 12.19ms

Requests:
  3,386,276 requests in 30.09s
  112,539.11 requests/sec

The throughput result was:

Vix.cpp: 112,539.11 requests/sec

For me, the most interesting part is not only that Vix.cpp reached 112k requests per second.

The more important signal is the p99 latency.

At 800 concurrent connections, Vix.cpp stayed at:

p99: 12.19ms

That is the best p99 latency result in this local run.

Crow result

Crow also stayed fast, but it was behind both Drogon and Vix.cpp in this benchmark.

Running 30s test @ http://127.0.0.1:8080/bench
  8 threads and 800 connections

Thread Stats   Avg      Stdev     Max   +/- Stdev
  Latency     8.30ms    5.31ms  92.21ms   80.21%
  Req/Sec    11.76k     2.54k   30.21k    72.62%

Latency Distribution
  50%    7.21ms
  75%   10.40ms
  90%   14.72ms
  99%   26.76ms

2809917 requests in 30.10s, 324.25MB read
Requests/sec: 93339.82
Transfer/sec: 10.77MB

The throughput result was:

Crow: 93,339.82 requests/sec

Crow remains simple and useful, especially for small C++ web services, but in this specific benchmark it was behind Drogon and Vix.cpp.

Summary table

Framework	Requests/sec	Avg latency	P50	P90	P99
Drogon	115,151.01	6.38 ms	5.49 ms	12.03 ms	21.16 ms
Vix.cpp	112,539.11	7.31 ms	6.51 ms	8.73 ms	12.19 ms
Crow	93,339.82	8.30 ms	7.21 ms	14.72 ms	26.76 ms

The comparison in one paragraph

On this local benchmark, Drogon is slightly ahead in raw throughput with 115,151.01 requests/sec, Vix.cpp stays very close with 112,539.11 requests/sec, and Crow reaches 93,339.82 requests/sec.

The most interesting part for Vix.cpp is the latency distribution: Vix.cpp had the best p99 latency in this run with 12.19ms, compared to 21.16ms for Drogon and 26.76ms for Crow.

That is the comparison I want people to remember.

Drogon is still ahead in raw throughput.

Vix.cpp is very close to Drogon.

Vix.cpp is ahead of Crow in this run.

And Vix.cpp has the best p99 latency in this benchmark.

What the numbers mean

The raw throughput result is close between Drogon and Vix.cpp.

Drogon : 115,151.01 req/s
Vix.cpp: 112,539.11 req/s

That difference is around 2.27%.

For a project like Vix.cpp, that matters because Vix.cpp is not only trying to expose HTTP routes. It also carries a bigger platform direction around the CLI, SDK profiles, modules, registry workflow, project commands, diagnostics, and production preparation.

So being close to Drogon at the HTTP runtime level is a good sign.

Compared to Crow, the difference is larger.

Vix.cpp: 112,539.11 req/s
Crow   :  93,339.82 req/s

That is around 20.57% more requests per second for Vix.cpp in this local run.

But again, the result I care about most is the p99 latency.

Vix.cpp: 12.19ms
Drogon : 21.16ms
Crow   : 26.76ms

Throughput is easy to look at because it gives one big number.

Latency is more interesting because it shows how the runtime behaves under pressure, especially near the tail.

A runtime can look good on average and still feel unstable when the tail latency grows too much.

In this run, Vix.cpp showed a strong p99 result.

Why compare Vix.cpp with Drogon and Crow?

Because those are the names people already know.

When someone talks about C++ web frameworks, Drogon and Crow usually come up quickly.

That is normal.

Drogon has a strong performance reputation.

Crow has a simple and familiar style.

So if Vix.cpp is going to be taken seriously as a modern C++ application platform, it needs to stand next to the tools developers already recognize.

This comparison is not about attacking Drogon or Crow.

Both are valuable C++ projects.

The point is to show that Vix.cpp is not only about developer experience. It is also moving in a competitive runtime direction.

Vix.cpp is not just another C++ web framework

This part is important.

Drogon and Crow are mainly focused on the web framework question:

How do I build a C++ web service?

Vix.cpp is trying to answer a wider question:

How do I build, run, test, package, extend, and maintain a real native C++ application?

That difference matters because most C++ friction does not come from the language alone.

It also comes from everything around the language.

Project setup.

Build configuration.

Dependency workflow.

Running examples.

Testing.

Packaging.

Installing runtime profiles.

Checking the environment.

Preparing a project for production.

Keeping the workflow understandable as the application grows.

Vix.cpp exists around that problem.

The HTTP runtime is one piece of it, but it is an important piece because modern applications often need APIs, services, realtime features, internal dashboards, tools, and backend workflows.

What this benchmark does not prove

This benchmark does not prove that Vix.cpp is always faster than Drogon.

It does not prove that Vix.cpp is always faster than Crow.

It does not prove that one framework is better for every workload.

A real application can change the result completely depending on what it does.

Database queries can dominate everything.

JSON serialization can change the profile.

TLS can change the cost.

Middleware can add overhead.

Logging can slow down hot paths.

Memory allocation patterns can become more important than routing.

Static files, request bodies, WebSocket traffic, cache layers, and business logic can all change the final behavior.

So this benchmark should be read honestly.

It is a simple local HTTP benchmark.

Nothing more.

But it is still a useful signal.

It shows that the current Vix.cpp HTTP runtime is already competitive on a basic high-concurrency endpoint.

Why the p99 result matters to me

The 112k req/s number is nice.

It looks good in a table.

It is easy to share.

But the p99 latency matters more to me because it gives a better signal about the runtime behavior under load.

In this benchmark, Vix.cpp did not only process many requests.

It kept the p99 latency lower than both Drogon and Crow.

Vix.cpp p99: 12.19ms
Drogon p99 : 21.16ms
Crow p99   : 26.76ms

That does not mean Vix.cpp will always win p99 in every situation.

But it does mean the v2.7.0 runtime direction is promising.

And that is what I wanted to verify.

The current position of Vix.cpp

After this benchmark, I would describe the current position like this:

Drogon is still slightly ahead in raw throughput.
Vix.cpp is very close to Drogon.
Vix.cpp is ahead of Crow in this local run.
Vix.cpp has the best p99 latency in this benchmark.

That is a good place for Vix.cpp v2.7.0 to be.

Especially because Vix.cpp is still growing as a full platform, not only as an HTTP router.

The goal is not to win one chart and stop there.

The goal is to keep building a C++ workflow that feels modern while staying native, fast, and understandable.

What comes next

This benchmark is only one step.

The next useful tests should be more realistic.

I want to test:

different concurrency levels,
longer benchmark durations,
JSON responses,
larger response bodies,
route-heavy applications,
WebSocket workloads,
middleware-heavy endpoints,
file serving,
real application endpoints,
different machines,
and different compiler configurations.

That will give a better picture than a single Hello World benchmark.

But this first comparison is still important because it gives a clean baseline.

Before testing complex applications, the runtime should behave well on the simplest endpoint.

Here, Vix.cpp does.

Final result

The final result of this local benchmark is simple:

Drogon : 115,151.01 req/s
Vix.cpp: 112,539.11 req/s
Crow   :  93,339.82 req/s

And the p99 latency result is:

Vix.cpp: 12.19ms
Drogon : 21.16ms
Crow   : 26.76ms

So the fair conclusion is this:

Vix.cpp v2.7.0 is very close to Drogon in raw throughput, ahead of Crow in this run, and shows the best p99 latency on this local benchmark.

That is a strong signal for the current direction of the HTTP runtime.

Vix.cpp is still growing, but the foundation is becoming stronger.

The goal remains the same: make C++ development feel more direct, more modern, and more reliable without hiding the power of the language.

Links

Website: https://vixcpp.com

Documentation: https://docs.vixcpp.com

Registry: https://registry.vixcpp.com

Engineering notes: https://blog.vixcpp.com

GitHub: https://github.com/vixcpp/vix

Vix.cpp v2.7.0 is out: a stronger foundation for native C++ applications

Gaspard Kirira — Tue, 30 Jun 2026 06:02:19 +0000

Vix.cpp v2.7.0 is out: a stronger foundation for native C++ applications

Vix.cpp v2.7.0 is out.

This release is an important foundation point for the project. Vix.cpp has been growing for more than a year, with the same goal from the beginning: make modern C++ application development more direct without taking away the native C++ model.

Vix.cpp is not a new language. It is not a replacement for CMake. It is not trying to hide the compiler or the native toolchain.

It is a runtime and developer toolkit around real C++ applications: create a project, run it, build it, test it, check it, install SDK profiles, manage dependencies, package the result, and prepare it for production.

What changed in v2.7.0

The v2.7.0 release brings together a lot of work across the CLI, SDK workflow, modules, diagnostics, release packaging, installer, and website direction.

The important part is not only that Vix.cpp has more pieces now. The important part is that those pieces are starting to hold together as one platform.

Vix.cpp now has a clearer split between:

the CLI bootstrap,
SDK profiles,
runtime modules,
registry workflow,
project commands,
diagnostics,
examples,
CI and tests,
release verification,
and real application validation.

The installer now focuses on installing the CLI first:

curl -fsSL https://vixcpp.com/install.sh | bash

On Windows:

irm https://vixcpp.com/install.ps1 | iex

Then SDK profiles are installed through the CLI:

vix upgrade --sdk list
vix upgrade --sdk info web
vix upgrade --sdk web

This keeps the first installation smaller and makes the SDK layer explicit.

SDK profiles

One of the important directions in v2.7.0 is the SDK profile workflow.

Different C++ applications do not need the same runtime surface. A small CLI tool, a web backend, a data application, a P2P system, a game-oriented project, or an agent workflow have different requirements.

So Vix.cpp separates the CLI from the SDK layer.

For example:

vix upgrade --sdk web info

shows the modules and system dependencies for the web profile.

The web profile is meant for APIs, realtime applications, backend services, middleware, WebSocket, validation, crypto, WebRPC, and requests.

The data profile is focused on database, ORM, key-value storage, and cache workflows.

This makes Vix.cpp easier to install, easier to validate, and easier to reason about as the platform grows.

Vix CLI

The CLI remains the main entry point into the Vix.cpp workflow.

A C++ project can be created and started through one command surface:

vix new app
cd app
vix dev

A single C++ file can still be run directly:

vix run main.cpp

And the project workflow stays consistent:

vix build
vix run
vix tests
vix check
vix fmt
vix pack

The goal is not to turn C++ into a scripting language. The goal is to remove repeated workflow friction around C++ applications.

Vix Note

Vix Note is also part of the developer experience.

It gives C++ developers a visual space for executable notes, examples, experiments, and diagnostics while keeping the normal Vix workflow underneath.

Start it with:

vix note

This is useful for documenting ideas, testing examples, and working with project notes in a way that stays close to the actual C++ workflow.

Performance signal

For v2.7.0, I also ran a local HTTP benchmark on my laptop.

This was not a cloud server or a dedicated benchmark machine. It was an HP EliteBook running Linux on x86_64 with 8 CPU threads.

The benchmark command was:

wrk -t8 -c800 -d30s --latency http://127.0.0.1:8080/bench

The result:

3,386,276 requests in 30.09s
112,539.11 requests/sec

The latency distribution was also encouraging:

Avg: 7.31ms
p50: 6.51ms
p75: 7.59ms
p90: 8.73ms
p99: 12.19ms

The result I care about most here is not only the 112k req/s. At 800 concurrent connections, keeping p99 around 12.19ms is a good signal for the current HTTP runtime direction.

This is still an early local benchmark. More testing is needed across different endpoints, concurrency levels, machines, and realistic workloads. But for the v2.7.0 direction, it is a good sign.

Registry direction

Vix.cpp also has a registry workflow.

The registry is intentionally simple at this stage. It is based on a transparent package index instead of requiring an expensive backend cloud service before the ecosystem needs one.

That matters because Vix.cpp is maintained by Softadastra, and the project has to grow with discipline.

The goal is to make package discovery, installation, updates, local store management, and publishing part of the normal Vix workflow without making the infrastructure heavier than necessary.

Pico and real validation

Vix.cpp is not being validated only through isolated examples.

Pico is a real application built with Vix.cpp. It exists to keep the runtime honest by bringing the pieces together inside a working application: routing, middleware, persistence, diagnostics, runtime behavior, and the workflow around them.

This is important because a platform can look good in examples and still fail when real application concerns meet each other.

Pico helps test whether Vix.cpp holds together as real software.

What happens after v2.7.0

After v2.7.0, the direction is clear.

The focus is no longer to keep adding more modules and more surface area.

The next phase is about depth:

improve existing modules,
strengthen the registry workflow,
improve SDK installation,
expand tests,
improve CI coverage,
refine diagnostics,
improve documentation,
make releases cleaner,
and keep validating Vix.cpp through real applications.

This does not mean Vix.cpp is waiting to become stable later. Vix.cpp is already usable.

The next phase is about maturity.

New features can still happen, but they should earn their place. A feature belongs in Vix.cpp when it improves the existing workflow, strengthens an existing module, or solves a practical problem for real C++ applications.

Install Vix.cpp

Linux and macOS:

curl -fsSL https://vixcpp.com/install.sh | bash

Windows PowerShell:

irm https://vixcpp.com/install.ps1 | iex

Then:

vix upgrade --sdk list
vix upgrade --sdk info web
vix upgrade --sdk web

Links

Website: https://vixcpp.com
Documentation: https://docs.vixcpp.com
Registry: https://registry.vixcpp.com
Engineering notes: https://blog.vixcpp.com
GitHub: https://github.com/vixcpp/vix

Vix.cpp v2.7.0 is a foundation release.

The goal remains simple: make C++ development feel more direct, more modern, and more reliable without hiding the power of the language.

Vix.cpp v2.7.0 benchmark: 112k req/s locally on an HP EliteBook

Gaspard Kirira — Thu, 25 Jun 2026 10:02:33 +0000

Vix.cpp v2.7.0 benchmark: 112k req/s locally on an HP EliteBook

I have been working on the v2.7.0 release of Vix.cpp, and I wanted to share a small benchmark from the current release build.

This benchmark was not done on a cloud server or a dedicated benchmark machine. It was run locally on my laptop.

Machine

Platform        : linux
Architecture    : x86_64
Kernel version  : 6.17.0-35-generic
Hostname        : softadastra-HP-EliteBook-x360-1030-G3
CPU count       : 8
Page size       : 4096 bytes

Build mode

The project was built in release mode with benchmark mode enabled:

vix build --preset release --build-target all -v --clean -- -DVIX_BENCH_MODE=ON

The server was running with:

Vix.cpp v2.6.0
Threads: 8/8
Mode: run
Status: ready
HTTP: http://localhost:8080/

The benchmark endpoint was simple:

curl http://127.0.0.1:8080/bench
# OK

Benchmark command

wrk -t8 -c800 -d30s --latency http://127.0.0.1:8080/bench

Results

Running 30s test @ http://127.0.0.1:8080/bench
  8 threads and 800 connections

Latency:
  Avg:   7.31ms
  Stdev: 16.26ms
  Max:   606.15ms

Latency Distribution:
  50%:  6.51ms
  75%:  7.59ms
  90%:  8.73ms
  99%: 12.19ms

Requests:
  3,386,276 requests in 30.09s
  112,539.11 requests/sec

Notes

The result I care about most here is not only the 112k req/s, but also the latency distribution.

At 800 concurrent connections, the p99 latency stayed around 12.19ms, which is a good signal for the current direction of the HTTP runtime.

This is still an early benchmark, and I will continue testing with different concurrency levels, different endpoints, and more realistic workloads.

For now, this is a good sign for the v2.7.0 release direction.

The goal with Vix.cpp is simple: make C++ development feel simpler, faster, and more modern without hiding the power of the language.

Softadastra is Becoming The C++ Tooling Company

Gaspard Kirira — Sun, 21 Jun 2026 09:43:31 +0000

Softadastra is Becoming The C++ Tooling Company

Softadastra is changing direction.

For a long time, the company explored different ideas around software, infrastructure, platforms, and developer products. Each idea had value, but over time one problem became more important than the rest.

Developer tools are still too dependent on perfect conditions.

Many modern tools are designed with an invisible assumption: the internet is fast, stable, and always available. That assumption works well in some parts of the world, but it does not represent the reality of many developers.

In many environments, especially across parts of Africa, the internet can become slow without warning. A connection can drop so low that downloading a dependency, reading documentation, installing a package, or using a cloud service becomes difficult.

When that happens, the problem is no longer just the code.

The environment around the code becomes part of the problem.

That reality has shaped the new direction of Softadastra.

Why this matters

Modern software development often depends on many external layers.

A developer creates a project, installs dependencies, configures a build system, connects tools, searches through documentation, runs tests, reads compiler errors, prepares a package, and eventually ships the software.

When everything works, this process feels normal.

But when the network is unstable, the machine is limited, or the tooling is too fragmented, even simple work can become unnecessarily hard.

Softadastra believes developer tooling should be built with more respect for those conditions.

Tools should not assume that every developer is working with perfect infrastructure. They should help developers keep control of their workflow, understand what is happening, and move faster without fighting the environment.

That is one reason C++ became the center of this direction.

Why C++

C++ is powerful, mature, and still deeply important in systems, performance-critical software, embedded environments, infrastructure, desktop applications, game engines, and developer tools.

But the experience around C++ can still feel difficult.

Starting a project is not always simple. Build systems can be confusing. Error messages can be hard to understand. Packaging can feel disconnected. Many parts of the workflow require experience before the developer can even become productive.

Softadastra does not want to make C++ less powerful.

Softadastra wants to make the experience around C++ better.

That means helping developers create projects faster, build with more clarity, understand errors sooner, test with less friction, package software more cleanly, and work with tools that feel connected instead of scattered.

Vix.cpp as the foundation

Vix.cpp is becoming the foundation of this direction.

The goal of Vix.cpp is to provide a modern tooling ecosystem around C++ development. It is not only about one command-line tool or one framework. It is about building a coherent developer experience around C++.

Softadastra wants Vix.cpp to help developers move from idea to working software with fewer obstacles.

A developer should be able to create a project, build it, test it, inspect errors, manage modules, package the result, and understand the structure of the project without feeling lost in disconnected tools.

This is the kind of experience Softadastra wants to build.

Built from a different reality

Softadastra is not choosing this direction because C++ tooling sounds trendy.

The direction comes from a real environment.

When developers build from places where infrastructure is not always reliable, they learn to value control. They learn to value tools that are native, direct, understandable, and less dependent on perfect network conditions.

That perspective matters.

The world does not need more developer tools that only work well in ideal environments. It also needs tools designed by people who understand what it means to build when the conditions are not perfect.

Softadastra wants to bring that perspective into C++ tooling.

The mission

Softadastra now has a clear mission:

To simplify C++ development.

That mission will guide the company’s work going forward.

Softadastra will focus on tools, workflows, documentation, diagnostics, packaging, and developer experience around C++.

The company is no longer trying to become many things at once.

Softadastra is becoming The C++ Tooling Company.

And Vix.cpp is the foundation of that future.

Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++ Runtime

Gaspard Kirira — Fri, 19 Jun 2026 11:22:19 +0000

Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++ Runtime

Vix.cpp v2.6.3 is now available.

This release is not about adding a huge new feature.

It is about making the foundation stronger.

Vix.cpp is a modern C++ runtime and developer toolkit for building real applications with native C++. It provides a workflow around C++ projects: running files, creating projects, building, testing, packaging, working with modules, and preparing applications for production.

With v2.6.3, the focus is stability.

This release improves the Core runtime, shutdown behavior, HTTP sessions, benchmark infrastructure, CI coverage, sanitizer support, module tests, JSON behavior, and several CLI workflows.

The goal is simple:

stabilize the runtime
measure performance
strengthen CI
make failures easier to trust

Why this release matters

A C++ runtime is not only about API design.

It also has to answer difficult engineering questions:

Does the server shut down correctly?
Are async operations cancelled safely?
Do pending tasks finish or get lost?
Can test failures be trusted?
Can benchmarks be repeated?
Does CI test the right source files?
Do sanitizer builds link and run correctly?
Can developers run existing CMake projects without fighting the CLI?

Vix.cpp v2.6.3 focuses on these areas.

It is the kind of release that makes the project less flashy, but more serious.

Better `vix run`

vix run is one of the most important commands in Vix.cpp.

It can run a project, a single C++ file, a .vix manifest, a binary, and other runtime targets.

In v2.6.3, executable resolution is more reliable for CMake projects.

Before, some projects could fail when the generated binary name did not match the project folder name.

Now vix run can resolve runnable executables more generically.

This also improves project watch mode, because the development workflow no longer assumes that the output binary must have the same name as the directory.

This matters for real CMake projects.

Not every C++ project is generated by Vix. Vix should work with existing C++ projects too.

Better `vix tests`

Long-running test suites need good progress output.

v2.6.3 improves vix tests so it can show clearer progress during long CTest runs.

The output can now show useful state such as:

completed
total
running
elapsed time

This release also fixes interruption handling.

When the user presses Ctrl+C, Vix now treats it as a user interruption instead of reporting it as a normal test failure.

That distinction matters.

A test failure means the code is wrong.

A user interruption means the user stopped the run.

The CLI should not confuse those two situations.

Core lifecycle fixes

One of the most important parts of this release is Core lifecycle stability.

The Core module is the foundation used by Vix HTTP applications. It connects the public application API with routing, sessions, async I/O, runtime execution, server lifecycle, middleware, requests, responses, and configuration.

v2.6.3 improves shutdown behavior across:

vix::App
HTTP server lifecycle
runtime executor shutdown
async TCP services
scheduler shutdown paths
pending coroutine operations

Some of the important lifecycle fixes include:

App::close() is now terminal, idempotent, and safe before or after listen().
App::wait() now closes the running server on signal-stop paths.
App::listen() prevents closed app instances from being restarted accidentally.
HTTP server shutdown ordering is safer.
The accept loop is allowed to drain before stopping the async I/O context.
TCP listener teardown is safer.
Server readiness is marked only after the accept loop starts.

These are not cosmetic changes.

They make the runtime more predictable under tests, shutdown races, signal stops, and sanitizer instrumentation.

HTTP session hardening

v2.6.3 also improves HTTP session behavior.

The release fixes parsing and error-response edge cases for:

malformed requests
invalid content lengths
oversized payloads
unexpected EOF bodies
case-insensitive Connection: close handling

A framework is easy to test when every request is valid.

Real servers need to behave correctly when clients send bad data, partial data, or edge-case protocol input.

This release makes that layer stronger.

Async shutdown improvements

Async shutdown bugs can be difficult to reproduce.

They often appear only under sanitizers, Valgrind, slow CI machines, or very specific timing conditions.

v2.6.3 improves async TCP shutdown behavior by making close paths safer.

The async TCP stream now cancels pending operations, shuts down the socket, and closes it safely.

The async TCP listener now cancels and closes the acceptor through the Asio executor.

Pending accepts keep the acceptor alive until completion handlers finish.

The scheduler shutdown behavior is also improved so pending coroutine handles are not silently destroyed before completion paths can run.

This helps make the runtime safer when applications stop quickly or when tests force lifecycle edge cases.

Runtime executor fixes

The runtime executor also receives important fixes.

Pending posted tasks are now drained before workers stop.

Idle detection now tracks accepted in-flight tasks before they begin execution.

This avoids a dangerous class of runtime bugs where the executor could appear idle while work had already been accepted but had not started yet.

The runtime worker shutdown path was also improved when yielding tasks are being rescheduled.

This makes task execution and shutdown more deterministic.

Official Core benchmark suite

v2.6.3 adds an official benchmark suite for Vix Core.
This is one of the most important changes in the release.
Performance should not be based on feelings.
It should be measured, stored, compared, and protected.

The Core benchmark suite covers:

runtime.task
runtime.queue
runtime.scheduler
runtime.worker

executor.submit
executor.post
executor.metrics

router.match
router.registration

http.request
http.response

session.fake_transport

app.route_registration
app.group_registration

The release also adds shared benchmark utilities for:

median time
mean time
operations per second
warmup iterations
measured samples
JSON report generation

This gives Vix.cpp a repeatable performance workflow.

Official v2.6.3 benchmark baseline

The official Core v2.6.3 Release benchmark baseline is stored under:

modules/core/benchmarks/baselines/v2.6.3/

The baseline was generated in Release mode on Linux x86_64 with GCC 13.3.0.

Benchmark comparison uses:

median_ops_per_sec

Higher is better.

Default thresholds:

WARN = -5%
FAIL = -10%

The benchmark workflow includes:

scripts/run_core_benchmarks.sh
scripts/compare_core_benchmarks.py

That means future changes can be compared against a known baseline.

If performance improves, it is visible.
If performance regresses, it is visible.

That is the point.

Release builds for real measurements

v2.6.3 also documents an important rule:

dev/debug = compile, test, debug
release   = measure performance

Debug builds are useful for development.
They are not useful for official performance numbers.
Official benchmark baselines should come from Release builds only.
This is the kind of rule that keeps performance discussions honest.

Stricter CI

v2.6.3 strengthens CI in several areas.

Core now has stricter coverage for:

debug/runtime builds
sanitizer builds
Valgrind memory checks
static analysis
benchmark builds
package export validation

The release also improves sanitizer coverage for Core lifecycle, shutdown, executor, session, server, and app behavior.

This matters because lifecycle bugs in C++ are often invisible until sanitizers or memory tools run the code under different timing conditions.

Better static analysis scope

Strict static analysis is useful only when it analyzes the right code.

v2.6.3 improves static analysis scope so third-party files, generated files, examples, benchmarks, and tests are not treated as blocking project source analysis.

This prevents vendored dependencies or disabled optional backends from blocking the release with irrelevant warnings.

The goal is not to make CI weaker.
The goal is to make CI stricter where it matters.

Blocking analysis now focuses on project source files and module implementation sources.

Style-only findings can still be reported separately without blocking the release.

Broader module test coverage

v2.6.3 improves module-level test coverage across the Vix ecosystem.

SECURITY_CI now builds and runs tests inside module directories instead of relying only on root-level test discovery.

This is important because many modules keep their tests close to the module itself.

The release also improves sanitizer-ready test coverage across modules such as:

async
cache
conversion
crypto
env
error
fs
game
io
json
kv
log
middleware
os
path
p2p
process
sync
template
tests
threadpool
time
validation
webrpc
websocket
agent

This makes the whole project more reliable as a modular C++ codebase.

JSON fixes

The JSON module receives an important JPath parsing fix.

Paths after bracket segments now parse correctly.

Examples:

users[0].email
["complex.key"].value

The release also improves JSON module testing, benchmark coverage, examples, and documentation.

This matters because JSON is a core part of many backend and tooling workflows.

Threadpool determinism

The threadpool module receives several deterministic behavior fixes.

v2.6.3 improves future handling for pre-cancelled and queued-cancelled tasks so they resolve deterministically instead of hanging.

Cancellation paths now report cancellation through the associated future.

Tests were also fixed so they do not assume asynchronous work finishes immediately after posting.

That is important.

Threadpool tests should prove behavior, not depend on timing luck.

Highlights

Here are the main highlights of Vix.cpp v2.6.3:

Improved Core lifecycle and shutdown behavior.
Fixed HTTP session edge cases.
Improved async TCP close and shutdown behavior.
Fixed runtime executor shutdown and idle detection.
Added the official Core benchmark suite.
Added the official Core v2.6.3 benchmark baseline.
Added benchmark run and comparison scripts.
Improved vix run executable discovery.
Improved vix tests progress and interruption handling.
Fixed JSON JPath parsing after bracket segments.
Strengthened Core test layout.
Expanded sanitizer coverage across modules.
Improved static analysis scope.
Fixed sanitizer linking for module tests.
Made threadpool cancellation behavior more deterministic.
Improved CI so it is strict without blocking on irrelevant files.

Why this matters for C++

C++ gives developers performance and control.

But building real applications in C++ often requires a lot of repeated infrastructure:

build workflows
test workflows
runtime diagnostics
dependency management
packaging
production checks
benchmark tracking
CI configuration
module boundaries

Vix.cpp exists to make that application layer more consistent.

v2.6.3 is a step toward that goal.
It makes Vix.cpp less fragile and more measurable.
It also makes the project more honest.
If performance changes, benchmarks should show it.
If shutdown breaks, tests should catch it.

If CI fails, it should fail for the right reason.

Links

GitHub repository:

https://github.com/vixcpp/vix

Release notes:

https://blog.vixcpp.com/posts/changelog/v2.6.3

Core benchmark baseline article:

https://blog.vixcpp.com/posts/vix-core/vix-core-benchmark-baseline-v263

Documentation:

https://docs.vixcpp.com

Final note

Vix.cpp v2.6.3 is not a flashy release.

It is an engineering release.

It improves the parts of a C++ runtime that must be trustworthy:

runtime stability
shutdown behavior
tests
benchmarks
CI
sanitizers
diagnostics
module reliability

That is the long-term direction of Vix.cpp:

native C++
modern workflow
measured performance
strict CI
production-oriented reliability

C++ deserves serious tooling.

Building an Official Performance Baseline for Vix.cpp Core v2.6.3

Gaspard Kirira — Tue, 16 Jun 2026 07:38:26 +0000

Vix.cpp Core v2.6.3: Official Benchmark Baseline

Today I reached an important milestone with Vix.cpp Core.

For the first time, I now have an official benchmark baseline for Vix.cpp Core v2.6.3.

This baseline was generated in Release mode on Linux x86_64 using GCC 13.3.0.

The goal is simple:

I do not want to say “Vix is fast” only because it feels fast on my machine.

I want performance to be measured, tracked, compared, and protected.

Why this matters

When building a C++ framework, performance can easily regress without being noticed.

You change a router function.
You improve an executor.
You refactor request parsing.
You clean up response serialization.

Everything still compiles.
All tests still pass.

But maybe the router is now 15% slower.
Maybe request construction got heavier.
Maybe the runtime scheduler is doing more work than before.

Without benchmarks, you may not see it.

With a baseline, every future change can be compared against a known reference.

That is why I started building the official Vix.cpp Core benchmark suite.

What is currently benchmarked

The benchmark suite currently covers several parts of Vix.cpp Core:

runtime queues
runtime scheduler
runtime workers
executor submit/post
executor metrics
router matching
router registration
HTTP request handling
HTTP response generation
fake transport sessions
app route registration
app group registration

This gives me visibility across both low-level primitives and higher-level web framework behavior.

Some results from the v2.6.3 baseline

Here are some numbers from the current Release baseline.

Runtime

runtime.queue/try_steal_empty                    132.6M ops/sec
runtime.queue/push_pop                            49.6M ops/sec
runtime.worker/steal_callback_complete_tasks       9.3M ops/sec
runtime.scheduler/submit_affinity_tasks            1.07M ops/sec

Router

router.match/static_route          9.37M ops/sec
router.match/nested_static_route   8.17M ops/sec
router.match/param_route           5.67M ops/sec
router.match/nested_param_route    3.91M ops/sec

This is useful because it shows the natural cost difference between static routes and parameterized routes.

A static route is faster.
A nested parameterized route is more expensive.
That is expected, but now it is measured.

Executor

executor.metrics/idle_reads        112.2M ops/sec
executor.submit/task_complete        465K ops/sec
executor.post/void_tasks             397K ops/sec

The executor benchmarks help track the cost of scheduling work, posting tasks, reading metrics, and handling different task execution paths.

HTTP

http.request/default_construct       10.7M ops/sec
http.request/json_cached_access      15.7M ops/sec
http.response/to_http_string_json    1.02M ops/sec
http.response/to_http_string_text     547K ops/sec

These benchmarks help protect the request and response layer, which is critical for Vix.cpp web applications.

Session

session.fake_transport/single_get_health      146K ops/sec
session.fake_transport/keep_alive_pipeline    248K ops/sec

This gives a higher-level view of request processing using an in-memory fake transport.

It is not the same as a real network benchmark, but it is very useful for tracking framework overhead without depending on external network noise.

Build mode matters

One important lesson: official benchmarks must not be generated from a debug/dev build.

A dev build is useful for testing and debugging, but not for official performance numbers.

For Vix.cpp Core, the rule is now:

dev / debug = compile, test, debug
release     = measure performance

The official baseline must come from a Release build.

How I want to use this

From now on, when I make a serious change inside Vix.cpp Core, I can run the benchmarks again and compare them against the v2.6.3 baseline.

If performance improves, I can prove it.
If performance gets worse, I can see it.
If a regression appears, it should not be ignored.

This changes the development workflow.

It moves performance from opinion to evidence.

Why I care about this

Vix.cpp is not only a C++ experiment for me.

I want it to become a serious foundation for building web services, runtime systems, tooling, and production applications.

For that, tests are not enough.
Documentation is not enough.
The framework also needs measurable performance discipline.
Benchmarks help create that discipline.
They make the project more honest.
They make future changes safer.
They make performance visible.

Final thought

Performance should not be based on feelings.

It should be measured.
It should be tracked.
It should be protected.

This v2.6.3 benchmark baseline is one step in that direction.

Vix.cpp is moving forward.

Vix.cpp v2.6.2: C++ Developer Toolkit Release with Windows SDK Installer Fix

Gaspard Kirira — Thu, 11 Jun 2026 08:57:19 +0000

Vix.cpp v2.6.2: C++ Developer Toolkit Release with Windows SDK Installer Fix

C++ development should not feel fragile from the first install step.

Today, we released Vix.cpp v2.6.2.

This release is focused on stability, packaging, registry workflows, dependency management, and better diagnostics around the commands developers use every day.

Vix.cpp is a modern C++ runtime and developer toolkit. The goal is to make C++ more practical for real projects: build, run, test, install dependencies, publish packages, deploy services, and debug issues with clearer feedback.

Windows SDK installer fix

One important fix in this release is the Windows SDK installer.

A user reported that the PowerShell installer was failing with a Not Found error while trying to download:

vix-sdk-windows-x86_64.zip

The report was correct.

The installer was trying to install the Windows SDK, but the release pipeline was not publishing the Windows SDK archive. It was publishing the Linux SDK asset, but not the Windows one.

This is fixed in v2.6.2.

The Windows SDK archive is now built, packaged, checksummed, signed, and uploaded as part of the release.

So this should now work correctly:

irm https://vixcpp.com/install.ps1 | iex

You can also force the version explicitly:

$env:VIX_VERSION="v2.6.2"
irm https://vixcpp.com/install.ps1 | iex

Better dependency workflows

This release also improves several registry and dependency commands.

vix update now respects version constraints declared in vix.json. It no longer blindly resolves direct dependencies to the latest registry version when a project has already declared constraints.

It also avoids reprocessing every dependency when only some dependencies actually need updates.

vix install now reports only dependencies that were actually installed or relinked. This makes the output much clearer, especially when working with an existing vix.lock.

vix list and vix outdated now show direct project dependencies by default. If you want the full locked dependency graph, you can still use:

vix list --all

and:

vix outdated --all

This makes the default output more useful for normal project maintenance.

Better `vix run`

vix run now works better with generic CMake projects.

Before, it could assume that the executable name matched the folder or project name. That is not always true.

Now it detects and runs the executable produced by the build, which makes vix run more useful outside of perfectly shaped Vix projects too.

Better diagnostics

v2.6.2 also improves diagnostics in multiple places.

CMake errors with multi-line message(FATAL_ERROR ...) output are now displayed more clearly instead of being collapsed into unreadable one-line messages.

vix tests failure output is now easier to understand. Failed test names, source locations, focused error messages, and compact code frames are summarized better.

vix.app also gives clearer errors when .vix/vix_deps.cmake is missing or when a required resource does not exist.

The goal is simple: when something fails, the tool should help you understand the problem faster.

Registry and package improvements

This release improves transitive registry dependency propagation.

For example, packages like rix/rix can expose dependencies such as:

rix/csv
rix/debug
rix/auth

without forcing every application to list all of them manually.

This is important for the direction of the Vix and Rix ecosystem.

Rix is the official package namespace for optional Vix.cpp libraries in the Vix registry. As more packages are added, dependency propagation needs to feel reliable and predictable.

Crypto helpers

v2.6.2 also adds new crypto helpers:

constant-time byte comparison helpers
PBKDF2-HMAC-SHA256 password hashing and verification helpers

These are small but important building blocks for security-sensitive code.

Why this release matters

Not every release needs to be about a big visible feature.

Sometimes the important work is making the normal workflow more reliable:

install
build
run
test
install dependencies
update dependencies
publish packages
deploy
debug
repeat

That is what v2.6.2 is about.

Vix.cpp is still moving toward the same goal: a modern C++ runtime and developer toolkit that is practical for real applications, not just demos.

Links

GitHub repo:

https://github.com/vixcpp/vix

Release:

https://github.com/vixcpp/vix/releases/tag/v2.6.2

Website:

https://vixcpp.com

Why I Started Building Vix.cpp

Gaspard Kirira — Thu, 04 Jun 2026 04:35:14 +0000

Why I Started Building Vix.cpp

C++ is one of the most powerful programming languages in the world.

It powers databases, browsers, operating systems, game engines, financial systems, and countless performance-critical applications.

Yet many developers still struggle with the same problems:

Project setup is often more complicated than writing code.
Dependency management is fragmented.
Build workflows vary from project to project.
New developers face a steep learning curve before they can build real applications.

After working on multiple C++ projects, I kept running into the same question:

Why is it easier to start a project in many modern languages than in C++?

That question eventually led me to start building Vix.cpp.

What is Vix.cpp?

Vix.cpp is a modern C++ runtime and developer toolkit.

The goal is not to replace C++.

The goal is to make building applications in C++ simpler, faster, and more productive.

With Vix.cpp, developers get a unified workflow for:

Creating projects
Managing dependencies
Running applications
Building releases
Running tests
Formatting code
Packaging software

All while staying fully compatible with the existing C++ ecosystem.

Why another tool?

Most C++ developers spend a significant amount of time dealing with infrastructure around their code.

Build configuration.
Dependency setup.
Project structure.
Tool integration.

These things are important, but they should not slow down application development.

Vix.cpp aims to reduce that friction.

Instead of spending time wiring tools together, developers can focus on building software.

The philosophy behind Vix.cpp

Several ideas guide the project:

Keep C++ native

Vix.cpp does not try to invent a new language.

Developers still write standard C++.

Make the common path simple

Many tasks should require a single command instead of multiple configuration steps.

Stay compatible

Existing compilers, libraries, and tooling should continue to work.

Improve developer experience

Good tooling helps developers move faster without sacrificing control.

Current status

Vix.cpp already includes:

A modern CLI workflow
Package management
Project templates
Build automation
Testing workflows
Formatting tools
JSON support
Database tooling
REPL support
AI tooling experiments

The project continues to evolve every week.

Looking forward

Vix.cpp is still early in its journey.
There is a lot left to build.
But the vision remains simple:

Make C++ development more accessible, productive, and enjoyable while keeping the power and performance that make C++ unique.

If that sounds interesting to you, I'd love to hear your thoughts.

GitHub:
https://github.com/vixcpp/vix

Documentation:
https://docs.vixcpp.com

DEV Community: Gaspard Kirira

C++ Needs Better Tooling Around the Project, Not Only Around Compilation

Building my official developer profile around Softadastra and Vix.cpp

Vix.cpp vs Drogon vs Crow: a local benchmark of the v2.7.0 HTTP runtime

Vix.cpp vs Drogon vs Crow: a local benchmark of the v2.7.0 HTTP runtime

The benchmark context

Benchmark command

Drogon result

Vix.cpp result

Crow result

Summary table

The comparison in one paragraph

What the numbers mean

Why compare Vix.cpp with Drogon and Crow?

Vix.cpp is not just another C++ web framework

What this benchmark does not prove

Why the p99 result matters to me

The current position of Vix.cpp

What comes next

Final result

Links

Vix.cpp v2.7.0 is out: a stronger foundation for native C++ applications

Vix.cpp v2.7.0 is out: a stronger foundation for native C++ applications

What changed in v2.7.0

SDK profiles

Vix CLI

Vix Note

Performance signal

Registry direction

Pico and real validation

What happens after v2.7.0

Install Vix.cpp

Links

Vix.cpp v2.7.0 benchmark: 112k req/s locally on an HP EliteBook

Vix.cpp v2.7.0 benchmark: 112k req/s locally on an HP EliteBook

Machine

Build mode

Benchmark command

Results

Notes

Softadastra is Becoming The C++ Tooling Company

Softadastra is Becoming The C++ Tooling Company

Why this matters

Why C++

Vix.cpp as the foundation

Built from a different reality

The mission

Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++ Runtime

Vix.cpp v2.6.3: Stability, Benchmarks, and a Stronger C++ Runtime

Why this release matters

Better vix run

Better vix tests

Core lifecycle fixes

HTTP session hardening

Async shutdown improvements

Runtime executor fixes

Official Core benchmark suite

Official v2.6.3 benchmark baseline

Release builds for real measurements

Stricter CI

Better static analysis scope

Broader module test coverage

JSON fixes

Threadpool determinism

Highlights

Why this matters for C++

Links

Final note

Building an Official Performance Baseline for Vix.cpp Core v2.6.3

Vix.cpp Core v2.6.3: Official Benchmark Baseline

Why this matters

What is currently benchmarked

Some results from the v2.6.3 baseline

Runtime

Router

Executor

HTTP

Session

Build mode matters

How I want to use this

Better `vix run`

Better `vix tests`

Better `vix run`