What really kills C++
WG21 has spent years arguing about contracts. I have a hard time thinking of a bigger waste of committee time. Now the C++26 draft has failed its ISO ballot, and people are arguing about the future of C++. I wrote about the ballot here.
Meanwhile, C++26 still has no pattern matching or string interpolation like Python’s f-strings. I would have liked to see both. How much further could we have got if we had spent some of that time on them?
Time to Hello World
Forget the committee drama for a moment. Start in an empty directory. Make a small program, add one dependency, and get it to run. How long does it take before you are writing code?
-
In Swift,
swift package init --type executable. Add the dependency toPackage.swift, list its product in your target, write the code, andswift run. Swift’s getting started guide -
In Go,
go mod init example.com/hello,go getthe package, writemain.go, andgo run .. Go’s dependency guide -
In Rust,
cargo new hello,cd hello,cargo addthe crate, editsrc/main.rs, andcargo run. Cargo’s first steps,cargo add
Did you notice that in all three cases you can go to the language’s home page and follow a guide all the way to a running project?
Hello World in C++?
Which IDE should you use? Which compiler? Which build system? There are plenty of C++ tutorials, but there is no single starting point with a default set of tools and one way to add a dependency.
Let’s say you pick CMake. Write a CMakeLists.txt and add an executable target.
Now, where does the library come from? vcpkg? Conan? The system package manager? Does the library support FetchContent?
You look and find CMake’s dependency guide. Does it help?
Eventually, you decide on a way to tell CMake how to get the library.
Then cmake -S . -B build and cmake --build build. Or learn how to put your configure and build settings in CMake presets.
Now you probably start to wonder whether you should have gone with Meson, xmake, or even Bazel. Or stayed with plain Makefiles.
Yes, all this can be quick if you already know the tools. If you are new, learning it adds more cognitive load than learning C++ itself. And even people who write C++ for a living can easily get stuck on dependencies and build systems.
Where should C++ go?
I expect WG21 to spend more time on networking, graphics, and other things that could live in libraries.
Let’s take contract_assert as an example. For everyday defensive programming, a simple library that checks conditions and lets people decide what to do when a check fails could do a lot of what is required. But for that to work well, and for everybody, we would need a package manager. One, not 23.
With a package manager, people can consume and test libraries more easily than today. Then different library ideas could compete, we would get implementation experience and feedback, and we could stay focused on the C++ language itself.
And solving package management would require fixing a lot of the other infrastructure issues as well. But it would serve not only C++, but C as well.
The infrastructure problem
Time to Hello World is a C++ infrastructure problem, and it is one that nobody in WG21 seems to want to touch.
There are plenty of excuses. I think where there is a will, there is a way. But I do not see any will.
Maybe it is easy to miss the problem when you can build Hello World yourself and call the build team for anything bigger?
- Therefore
-
-
Some people start their next project in another language.
-
Some never start their first C++ project at all.
-
And that, more than anything else, is what will eventually bring C++ down. Not whether we have contracts, or which flavor they come in.
Don’t get me wrong: the code we already have could stay around for decades. But maybe C++ has a COBOL future.
Bonus exercise: If you think the build example is too simple or not telling, compare how you create code coverage reports in each language.
If you find this page useful, donate a coffee to the C++ user group of Stockholm, SwedenCpp