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 (C)

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

To add more:

Regarding DBs, there is also ScyllaDB which really take advantage of the modern C++ realtime application design.

DBus is just a spec, the reference implementation is in C, but for example QtDBus is in C++.

Also the original unix predates C++ by ten years at least [1], so it is unsurprising that all descendants (direct or not) are written in C.

[1] C was designed to implement unix in the first place.

I'm not debating that there are a lot of projects written in C++. I only argue that C is enough to be able to learn about state-of-the-art tech in this area.

I'm not even going to debate C++'s merits at this point. Everybody's had enough of that already. There are people who stick to it and there are those who bailed after a while. It's just that, if I have a choice, I won't work with the people who belong to the former group.

for what is worth, GCC is no longer just C compiled as C++ as a lot of stuff is being and has been ported over to proper C++ classes, RAI and templated containers.

Pleasantly surprised at how different every C++ project is because they each have to mandate their own C++ subset in order to tame it's ridiculous complexity?

I get what you're saying, C++ is worlds away from where it was even 15 years ago. Don't downplay it's complexity though.

I dont think I made any references to complexity in my tweet.

All I was trying to say is that the bad news with respect to C++ is priced in and the language only has to be marginally better than what its detractors make it out to be.

> each have to mandate their own C++ subset in order to tame it's ridiculous complexity?

this one of those things that keeps getting repeated, but at least personally I have never seen in the wild.

Yeah, in my experience whenever a new C++ feature becomes available there is always someone who really wants to shove it in the codebase everywhere.

As Carmack once said, if it compiles, it'll find its way in your codebase.

IMHO a language's complexity is proportional to the square of the number of bnf rules. By this measure C++ is a disaster. If Thompson and Ritchie had tried to write UNIX in C++ they would have certainly failed!

All the old c++ is still here though, as always is a language where it’s hard to understand all of it.

From experience: it's worse. Words can't describe it

Today I stumbled upon metaclass proposal for C++ [0].

All I can say is that there should be a variation of Greenspun's tenth rule:

Any sufficiently complicated programming language becomes an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Still, I want to have that C++.

--

[0] - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070... the examples from the later parts of the paper show how great it would be to have something like that in C++.

I can already imagine trying to debug a templated type error with code that was generated at compile time...

No need to imagine, it happens all the time in D, and it's not that bad.

The errors aren't that bad. It's just a log of what you tried to do. Usually the first error is the only one that matters anyway

How does this differ from code generation?

It doesn't generate artifacts that you can examine and debug.

Circle seems to have compile-time printf, which would make it easier to debug than normal C++ compile-time code.

Depends if one is on the IDE camp or rather programs like PDP-11 was around.

It's portable and doesn't add any new build dependencies. No need to model extra phases in your build system either.

It would seem that most mainstream languages other than C/C++ have already bit the bullet on fancy build systems, due to dependency management, so codegen is not that expensive.

Any code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build it and then write the results to your final executable code?

While most ecosystems are moving to hermetic, reproducible builds this is going full steam on the other direction. Goodbye 'it works on my machine' hello 'it works on Jane's machine when Ryan builds it on Tuesdays. Oh Ryan WFH on Tuesday so it gets built on his home machine!'

I wanted to like this but it seems to have gone way too far. It is a college project gone wild.

If you do any codegen can't all of that already happen though? Many (most?) build systems can already execute more or less arbitrary logic. Reproducible builds are only guaranteed if you actually verify the signature of the output.

There's also runtime reflection in most dynamic languages, and don't forget self modifying code! No technical restriction can prevent people from writing bad code at the end of the day because bad code is really a social issue.

The difference is that code generating build actions are necessarily and explicitly called out in build systems - with the opportunity to observe their declared dependencies and sandbox their execution.

In circle compiling any cxx file executes arbitrary code and emits different results. There's no way to reason about what will happen during the build without manual inspection and that really doesn't scale past trivial projects. I'd imagine most static analysis and ide tools would be significantly hindered understanding circle code.

It is concerning that one of the first dozen examples of the language show how the compiler can request input from the terminal mid-compilation. Amazingly powerful feature put forward without any commentary about how / when it should be used or not used - let alone if it should exist at all. As I said it feels like a college experiment - it doesn't feel like they asked how these features would make it easier to write clear, understandable, maintainable code - they just implemented them.

I think reading through all the examples https://github.com/seanbaxter/circle/blob/master/examples/RE... makes it clear that the author has put quite a deal of thought into how these features make it easier to write clear, understandable and maintainable code.

Even the example you point to goes to say: "Let's use the integrated interpreter to define a useful build tool. Software is the subject of constant revisions, and it's useful to mark a distributable with the exact version of the source-control archive it was built with." It's clear (to me) that the developer is not advocating using terminal input in the middle of a build. I haven't used terminal input since I was a child; I don't think the developer expects anyone to take that as a serious example.

> code you compile can now execute arbitrary syscalls, shell out to git, interact with the user's terminal, host a web service or whatever else as you build it and then write the results to your final executable code?

There is no way you can get 100% reproducible builds without using an isolated sandbox with 'modern build tools' anyway (npm, cargo, pip, etc etc). They love to depend on hidden files in your home directory or download some random staff in your back.

This will be no different.

This works during template instantiation. So your macros can respond to types and values from such parameters. Also it seems to know about scopes.

Is this a benefit or a crutch or a mix or an implementation trade-off? I am still learning modern cpp.

C++ meta classes will primarily be useful for library authors. It is not expected that you have to write them yourself. They can document and enforce some pattern (e.g. an interface) or provide boilerplate that would currently need either macros or, well, boilerplate.

But I don't understand what you mean with "an implementation trade-off"?

Sure, sure. As soon as you replace megatons of code running all kinds of stuff. I'd suggest finishing off COBOL for starters.