DEV Community: Gaspard Kirira

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

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

Why I care about this

Final thought

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

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

Windows SDK installer fix

Better dependency workflows

Better vix run

Better diagnostics

Registry and package improvements

Crypto helpers

Why this release matters

Links

Why I Started Building Vix.cpp

Why I Started Building Vix.cpp

What is Vix.cpp?

Why another tool?

The philosophy behind Vix.cpp

Keep C++ native

Make the common path simple

Stay compatible

Improve developer experience

Current status

Looking forward

Better `vix run`

Better `vix tests`

Better `vix run`