This is where C++ is headed anyway. There's just a little bit more work that's needed in c++23, but it's planned, and that will make it possible to use a lot more of the STL in consteval/constexpr contexts.
I think this is a killer feature. Between execution policies and constexpr-all-the-things, I really think C++ is set to pull away in a way that other languages will have difficulty competing with.
When I read the first sentence I thought this was sarcasm. Then I realized it's not.
I can't help but think C++ will be one of these things digital archeologists will look back in disbelief.
And I mean both amazed as well as flabbergasted disbelief.
The disdain about C++ is now so overdone that I think that people who actually sit down with the language will be pleasantly surprised.
I used C++ professionally for over 20 years until recently.
What pleasant surprise(s) exactly are you talking about?
Actually, never mind.
After a year of Rust I see myself touching C++ code next when I'm 70 and they need some old farts to fix code no one can or wants to touch any more.
And they pay five digits/day (adjusted for inflation) for that service by that time. Now that will be the only 'pleasant surprise' I presage coming from C++ to me in the foreseeable future. ;)
Here is one possible pleasant surprise if I was starting out today - if my calling in life was to be a systems programmer then learning C++ opens up a rich sea of codebases built by people who knew what they were doing in the last ~25 years.
Irrespective of what language you actually choose to write your project in, if you want to learn how databases, caching servers, language runtimes, compilers, allocators, message buses, games, rendering engines, browsers, distributed systems, AI runtimes etc are implemented then the cutting edge as it exists right now is mostly written in C++.
Sure I hate the notation and the language as much as the next guy but I would hesitate to turn down the learning opportunity from so many cutting edge codebases.
In some ways it is analogous to math - lets say you hate the formalisms, symbols and terminology used in set-theory or in calculus, would you refuse to learn it if you knew that learning the formalism allows you to tap into 300 years of accumulated wisdom from some of the brightest minds that went on to do math?
C will more than suffice in this case.
> C will more than suffice in this case.
Clearly no. Any complicated enough system software in C finish quickly in a mess of void* , macros and buffer overflow.
Even making something as trivial as an hash map goes quickly in void* / macro mess in C.
It is for a reason that most system side services (or game engines) are written in C++ nowadays.
I was replying to this part:
> Irrespective of what language you actually choose to write your project in, if you want to learn how databases, caching servers, language runtimes, compilers, allocators, message buses, games, rendering engines, browsers, distributed systems, AI runtimes etc are implemented then the cutting edge as it exists right now is mostly written in C++.
First things that come to mind when one hears:
- databases: PostgreSQL (C), MySQL (C), Berkeley DB (C), SQLite (C)
- caching: memcached (C)
- language runtimes: Java (C++), Python (C), Go (Go), Chez Scheme (C + Scheme)
- compilers: GCC (C compiled as C++), Clang (C++), GHC (C + Haskell)
- allocators: glibc malloc (C), jemalloc (C), tcmalloc(C++)
- message buses: DBus (C)
- games: some people write C, some people write C++, some people write C# and some write Swift
- rendering engines: C++ is admittedly popular here, if that's your thing
- distributed systems: this thing is so hyped that it's implemented in every language in existence
- AI runtimes: people here change the language every 2 decades. they started with Lisp, now it's C++ + Python, later it will be JavaScript
- browsers: I pity anyone who has to work on this software (I have to)
Now let's add one obvious category which was suspiciously left out from this list: operating systems: Unix, BSDs, Linux, Plan 9, Illumos, GNU Mach, Windows NT, XNU --- there is almost no C++ here (and any C++ that there is in just the last two).
So personally, if I were to write something new in this area, I would choose neither C, nor C++, but when it comes to learning something, it's clear that C is more than enough.
I've been working a lot with C++. I've seen its horror. No more.
MySQL and MariaDB are a mixed of C++ and C nowadays [^2] [^1]. Most Database reimplementation nowadays are C++, Go or more recently (Rust).
> - message buses: DBus (C)
ZeroMQ is C++, Same for gRPC (reference of RPC nowadays), same for Thrift [^4]
> - games
Almost all triple A use the Unreal Engine or an home made engine in C++. Even Unity that brand itself as C# uses some C++ internally.
> distributed systems
Almost all Distributed system in the HPC world is C++ or Julia nowadays, with a bit of Fortran surviving.
> - AI runtimes
AI means often GPU usage, GPU usage means CUDA, meaning C++. That's valid for the today three main contenders (Tensorflow, pyTorch, MXNet ) and they all provide a python API on top of C++.
> Now let's add one obvious category which was suspiciously left out from this list: operating systems: Unix, BSDs, Linux, Plan 9, Illumos, GNU Mach, Windows NT, XNU --- there is almost no C++ here (and any C++ that there is in just the last two).
C++ is also in Fushia (Google) and BeOS/Haiku. But OS are mainly C (or Rust nowaday) because kernel space. Exception handling is problematic in kernel space.
[^1]: https:/github.com/MariaDB/server [^2]: https://github.com/mysql/mysql-server [^3]: https://zeromq.org/ [^4]: https://github.com/facebook/fbthrift