> Remember, it was the first language taught to older millennials for a reason.

For the reason that it was the only reasonably available language for a while, I'm afraid. I too have written enough C++ in my professional works; nowadays I work with Rust and Python though, my last professional C++ was C++14. And C++ only kinda works when someone with enough mistakes and thus enough knowledges organize the code base in the way that others won't easily make such mistakes. The language doesn't really help you---which is often a pro, but much more frequently a con. That's not a good place for beginners to start at the very least.

> For the reason that it was the only reasonably available language for a while

Weren't there other popular, cross-platform programming languages in the 1990s and late 1980s? Like Pascal, and Basic? Those both seem like simpler languages, and easier to teach as first programming languages than C++.

Yeah, I was missing a word there but I couldn't think of the exact word. I believe Pascal and Basic were usually regarded as teaching languages as opposed to practical languages, so (while I'm against such line of thoughts) many colleges and universities decided to go straight into production languages because they will need them after graduation anyway. Later Java and Python were used as that kind of "practical first languages".

That makes sense. I've heard that sentiment about "teaching languages".

I wonder how Pascal ever became so popular given that it was regarded as a teaching language. It was clearly a contender in industry for a while; for example, Apple originally used Pascal for the Macintosh, and Turbo Pascal was extremely popular.

Nowadays, we don't even have "teaching languages". Students are taught something like Python, JavaScript, or Java.

My experience of the language has been similar, including the bit about it no longer being part of my life.

For a long time, the complaint was that it was being used as nothing more than a "better C", though in my experience, the worst abuses came from among those who were determined to use every feature.

In the beginning, the fact that early C++ was a superset of C is probably what led to its widespread adoption, but the legacy of that decision, particularly with regard to pointers and pointer arithmetic, has been a multiplier of complexity.

Sometimes pointer arithmetic is the best implementation; are you implying that C++ would be better off without access to this feature?

I very rarely find a use for pointers anymore. Often a whole program has none at all, not even unique_ptr<>. When I do use them, they are front-and-center enough to make mistakes unlikely.

I also rarely use them, but sometimes pointers (via virtual methods and factories) can reduce compile times a lot for components with a stable API but high complexity and churn of the internals. Do you have another way to handle that?

I tend to rely on member unique_ptr for such concerns. At top level, you still don't see any pointers. Of course at machine level the code is absolutely lousy with pointers, likewise at the next level up, but the pointers you can't see because they are buried in libraries cannot generate bugs.

The D language dynamic array, which is a pointer+length pair, has (over time) nearly completely supplanted pointer arithmetic. The pair prevents buffer overflows and underflows.

Raw pointer arithmetic is not allowed in code marked @safe.

I've proposed it for C and C++:

https://www.digitalmars.com/articles/C-biggest-mistake.html

It would be simple to add it, and would be legacy compatible.

I surmised it would be less complex.

I'd say a lot of this is a form of survivorship bias. I've programmed in C++ since the mid 90s so I am used to a lot of C++'s issues, but I also run a company and have to train new engineers and I see first hand the absolute nightmare that a lot of people encounter learning this language and it's demoralizing. While to me a lot of this is stuff I managed to figure out, I also understand that for many new developers this is just crap that no one should have to deal with in 2023.

Lack of a good way to build third party libraries, build times that are astronomical and a true productivity killer, error messages that are entirely unhelpful and can produce giant walls of text for the most trivial of reasons, rampant undefined behavior that is incredibly hard to identify.

Several things changed my view on C++ and now I see it mostly as a sort of zombie language.

1. As I mentioned once I started my own business and needed to train new engineers on how to use C++, I started to look at the language from a fresh point of view and realized it really is a complex mess just to get basic things working.

2. Scott Meyers "retiring" from C++, and in particular this video:

https://www.youtube.com/watch?v=KAWA1DuvCnQ

3. I attended an ISO C++ meeting in Toronto and while I absolutely found that the people were very intelligent and knowledgeable, as well as well intentioned, I realized just how political C++ is and that much of its development and complexity is not due to technical constraints or driven based on what is in the best interest of the C++ community or research, but really based on name recognition and a lot of politics.

Unfortunately Bjarne himself has been responsible for a lot of political issues with C++ that could have easily been avoided such as the obvious warts with brace initialization and the paper he wrote that basically pushed out two of the most prominent members of the C++ community, Walter Bright and Andrei Alexandrescu over what seems like a bitter pissing contest he had with them:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n36...

C++ has had some improvements in the past decade for sure, but its future doesn't look too bright at this point. Features like modules are a convoluted mess that still don't work even 4 years after standardization. Coroutines are a lifetime and performance nightmare that was originally designed in particular to accommodate embedded platforms with no runtime, but are all but useless for that use case due to how they allocate memory, and concepts are really just a substitution of one hacky way of doing overload resolution with another hacky way of doing it.

Bjarne and I met at a conference a couple summers ago. We had a nice conversation and there's no ill will between us.

> Coroutines are a lifetime and performance nightmare that was originally designed in particular to accommodate embedded platforms with no runtime, but are all but useless for that use case due to how they allocate memory, and concepts are really just a substitution of one hacky way of doing overload resolution with another hacky way of doing it.

Coroutines were originally pushed by Microsoft, based on .NET's async/await model, and C++/CX concurrency on WinRT (COM evolution) runtime.

Hence why you will find several talks and papers from Gor Nishanov, during C++'s coroutines early days, or that .NET has a similar way of adding magic methods to a class to transform it into a coroutine aware type.

I really enjoy programming in C++, but agree on knot being able to know all of it. It’s just not necessary to know it all. I think this comes with programmer experience too, learning to learn what one needs to know right now along with some very high level of whats available goes a long way. Then when one needs to reach elsewhere, they have an idea of where to go, but none of the details yet. But knowing how to program also means that a large chunk of the problem of using the best language for the job is easier. Doing it idiomatically though, that takes work, but at least knowing the questions is a big start.

IMO C/C++ are great languages if you learn how memory and pointers etc. work. The tooling on the other hand is horrendous when you compare it to other languages like Rust.

You don't really need to do much explicit memory handling in modern C++ - smart pointers feel similar to garbage collected languages like Java or Go, with the occasional extra '*' I guess.

Comparing language tooling to Rust is surely controversial when compiles in Rust take an order of magnitude longer than any other language. Sure, Rust's tooling has some nice features but let's not ignore this very important elephant in the room.

> Comparing language tooling to Rust is surely controversial when compiles in Rust take an order of magnitude longer than any other language.

Do you have any source for that other than a hello world? I always read that both C++ and Rust take about the same amount of time.

Hang on just a sec

  Updating crates.io index
     Fetch [>                ] 0.12%

Cargo is i) not a compiler, and ii) moving to the sparse index protocol [1] that do not fetch the whole index anyway. And even the older git protocol won't fetch the same data twice.

[1] https://doc.rust-lang.org/nightly/cargo/reference/registry-i...

As a fairly avid Rust user I can say I'm excited to hear that! Just playing a little devil's advocate for fun.

That said I was moderately upset by this Friday after carefully assembling a development container for a project at work. Guess I'll have to make something persistent somewhere if I don't want to twiddle my thumbs before each build.

Cargo or not you probably should do that for your container, or use a shared cache (which I do at work for both Cargo and pip) ;-)

> Comparing language tooling to Rust is surely controversial when compiles in Rust take an order of magnitude longer than any other language.

The great benefits brought by having a standard tooling that actually has useful diagnostic and packaging makes any kind of slowdown tolerable.

Unless you code holding your piss.

> C++ is a big, complex language

And therein lies the actual problem. C++ killed the one saving grace of C, it's relative simplicity, and created a language that is a dumping ground of ideas.

The notion that you just "learn what you need" is an anathema. Not knowing a language, and all it's subtleties, is just a form of hacking. You end up encountering things which you don't understand and have to hope you don't cause unknown problems and muddle through.

That C++ is widely used by professionals who don't understand their tools is just another reason why software is so crappy these days.

Right... doing that specialized subset of a language that makes sense for you might not make sense for your team, might not make sense for your next team, and so on.

Plus, every library is using a different subset, so it’s not as if you can stay within your preferred subset either.

I worked in a project that had 6 different string classes: std::string, opencv, vtk, qt … plus a wrapper around all of the above that converted this mess to a plain C string so you could actually use it. A real nightmare, with no good way out.

I’m sure some C++ person will say “it’s not the fault of the language, it’s simply that those libraries are not proper C++23”, missing the fact that those are some of the most prolific, well-maintained and widely used projects in the C++ world. If even those can’t get it right, then the problem must surely lie with the underlying language itself, and with the committee who is defining how it’s supposed to work.

> If even those can’t get it right,

Most likely they do get it right for their problem domain. If the people who made opencv, vtk and qt had to make it in another language with the design constraints they had (which can sometimes be as simple as insisting on using CamelCase instead of snake_case for historical reasons) they would likely make their own string / array / matrix / ... type in that language too tailored to their exact problem domain.

> C++ killed the one saving grace of C, it's relative simplicity, and created a language that is a dumping ground of ideas.

I think the average C++ programmer is pretty aware of the language's downsides. It's still a language with important practical upsides though: there are plenty of C++ programmers out there for hire, there are many existing C++ projects that need to be worked on, and it has a strong ecosystem of compilers and libraries.

There seems to be little prospect of C++ losing its near-monopoly in core game-engine code, for instance.

(I say all this as someone who usually gives C++ a hard time for its poor safety, and associated security issues.)

> That C++ is widely used by professionals who don't understand their tools is just another reason why software is so crappy these days.

No doubt there are many security issues with those roots, and many instances of code that's needlessly non-portable. Those are due to specific issues with C++ though, not its general complexity.

I imagine the practical consequence of the language's complexity is to drag out development times, rather than to undermine software quality. I haven't given this too much thought though, and this is essentially a guess.

> The notion that you just "learn what you need" is an anathema.

I agree this idea makes little sense. If you work in a team, you may be asked to debug someone else's code. If you're going to work with C++, there's no denying the value in having a deep knowledge of the language.

To add to this, you can easily learn to use the newest features. I cringe every time I read or hear "C++ has become so huge and complicated". It only takes 20 minutes to get proficient in the newest features such as modules and concepts. People hear "polymorphic lambdas" and imagine something so complicated, it came out of the Necronomicon. No, you simply replace your lambda parameters with auto and the compiler takes care of the types and that's it. And variadic templates aren't going to eat your soul if you can read code that has recursion.

It isn’t as hard as people make out but it also isn’t easy. The saving grace is that the language, particularly in its modern form, is highly amenable to an experienced user designing their own libraries that make the language much nicer to use. You can replace most of the dubious parts. Nonetheless, C++ is unreasonably large.

The main advantage of something like C++20 is that for some types of software there is no other language that comes close in both performance and economy. The alternatives either require much more code or giving up a lot of performance, neither of which is particularly palatable for many use cases. I am always keeping an eye out for smaller languages with similar economy and performance.

Can you give an example of replacing a dubious part? I'm not sure what you mean.

> The main advantage of something like C++20 is that for some types of software there is no other language that comes close in both performance and economy.

Um, there are plenty of Crab People[0] around here who would quibble with that statement.

[0] https://en.wikipedia.org/wiki/Crab_people of course.

I used to love C++, template wrangling :-P aah, but pretty much gave up after C++11. Right about the time when Scott Meyers also said: "enough" (paraphrasing).

My biggest issue for giving up was the ever growing list of "don't"-s, its not fun to write in language where the design is so "loose" that to get reasonably correct/predictable code you always have to reference the list of "don't"-s.

And then having been a build maintainer on various projects the build and package management was a nightmare. Still vividly remember the first time I looked at Rust's cargo - mind blown :-)

> pretty much gave up after C++11

IMHO C++11 changes (and many of the later ones too) make the language substantially better than it was prior.

I do personally hate the package management story which is why I try to only use single header libraries (I only use C++ for personal projects so I have control over what I use). I absolutely despise cmake, but Rust’s cargo is fantastic.

The toolchain is completely unhelpful though. I can't make sense of half the compiler diagnostics that get spewed on my screen. If it wasn't for ChatGPT being able to reason about the compiler diagnostics, I'd be screwed.

Chatgpt didn't exist a year ago, what did you do then!

I guess I'm lucky I've only been doing a spate of C++ for about 18 months. In the early stages before ChatGPT it was a bit tough but I was also working with admittedly simpler code (less templated code). I have a decent grasp of C including virtually every compiler/linker error that a C compiler would spit out, so I could manage a lot of the superset style errors, but as more C++ work came in, the more inscrutable the diagnostics.

> because it’s so flexible yet so expressive.

False, Python is much more flexible and expressive than C++

Can you express value semantics in Python, or is everything still passed by mutable reference still and duck-typed at runtime? I’m being flip, and I like Python for some things, but for large robust performant software I find C++ way easier to work with as it works with me not against me to wrangle complexity.

If you know C++ inside out, it's very tricky and frustrating.

I think the problem is that it's "easy" to learn it well enough that you think you know it pretty much all.

But you're still far off and you get frustrated!

The expressitivity is a big one for C++.

When I started working in C# the loss of expressiveness was one of the most painful things about it (and I started back in the 1.1 days).

Even something as simple as aliasing typenames, C# FINALLY got it in the most recent version.