The industry prevalence, the community size, the installed codebase size, C compatibility, ability to write code at any level of abstraction, etc. makes C++ THE "Industrial Language" to learn.

I keep telling everybody to learn C and C++ irrespective of whatever else they might be forced to study/use since these literally gives them the ability to work at any level in the Software Stack; C is the "universal glue language" and C++ is the all-encompassing monster :-). Bored writing User mode Applications? Jump into writing Libraries/Frameworks/Kernel/Bare-metal code; all using the same familiar language and toolchains. Familiarity trumps everything else. I myself have successfully transitioned from writing Windows desktop apps(16/32-bit) to Network Protocol state machines to Kernel drivers and Bare-metal MCU code all using C/C++.

"Modern C++" (C++11 and later) has shifted the learning goalposts somewhat but nevertheless all the pre-C++11 knowledge is still the bedrock on which to build the new edifices. As a side-note, i completely disagree with people (mainly the "Modern C++" proponents) trying to divorce C++ from its C roots.

Other than C++, the only other language i am willing to spend time on from a professional/industrial pov is Erlang due to its concurrent/distributed/fault-tolerant features.

I would have agreed with you for many years, but I feel that we might be at an inflection point right now.

For many years, all new languages that got any traction at all were higher level, a bit (or a lot) slower, much more memory hungry than C and C++ and came with a huge runtime of their own.

These languages have largely replaced C++ for application development, but they are clearly less suitable for lower level tasks such as writing operating systems, drivers, ML frameworks, game engines, browsers, graphics libraries, embedded systems and libraries that are supposed to be usable across language runtimes.

But now there's Rust, which fixes a number of C++ weaknesses, comes with more modern infrastructure (such as cargo), and appears to have significant support within some of the largest corporations.

It's still very much an open question how this is going to end, but for the first time in my life as a professional developer (starting in the early 1990s), I wouldn't be surprised if C++ was in very gradual but terminal decline.

Then as much I love borrow checker and being safe by default, there are a couple of C++ domains where Rust isn't even a though in 99.9% of the eco-system.

Just consider that Apple has decided to create a C dialect (basically turning all the knobs to be safe by default) instead of Rust for their iBoot firmware.

I am quite sceptical that this will ever happen. C and C++ are fated to live together and forever :-)

The "accidental" rise of Web Applications gave a fillip to other languages simply because most of the early programmers were non-CS people. But once these apps hit their limits at scale they had no other option but to fallback to C++. So most often you only have a shim/skeleton app written in some other language whereas the libraries/guts are all written in C++.

Up until the pandemic hit, for several years running, more people attended each ISO C++ Standard meeting (in places as far-flung as Hawaii and Prague) than any previous meeting. Attendance at C++ conferences, and at the same time the total number of C++ conferences, including for smaller and smaller regions, has shot up year after year.

So any perception that C++ use is in decline, or even not exploding, is wholly a product of propaganda. C++ people code while others hype.

But that‘s not even what I‘m talking about as it merely reflects the fact that C++ has been replaced by higher level languages for development of regular business applications.

What I‘m saying is that now for the first time there is actual momentum behind a language that is a suitable replacement for C++ in its remaining core domains.

And that momentum is driven by serious computer science concerns within large companies rather than by the usual suspects when it comes to hype cycles.

I‘m not predicting C++‘s decline. I‘m merely saying that it would no longer surprise me as there is now both the substance and the momentum to drive such a development.

Also it seemed no matter how well I learned the language there was always something there to trip me up.

Faster build times help as well (one project went from 10 minutes to less than one whilst increasing the feature count).

I still write some C++ but only if I can't avoid it.

I still use a subset of modern C++ when I'm doing something cross-platform, and Qt helps, but it too often felt I was fighting a war on two fronts (the language, and the problem) when I was trying to keep up. So I gave up trying. And life is a lot happier now.

As a Mac guy, I still think ObjC (yes, I know, you don't like the syntax) was pretty much at the optimal level of complexity and performance. Not as fast as C++ in general, but plenty fast enough for 99% of things. Wonderful standard library with Foundation, and ARC really works well - memory management just isn't a thing I have to think about when I'm using it.

Swift ? Well, now I'm in the "I hate the syntax" camp :) I like my code to look neat (which is easy with C++ and C) and Swift just looks fugly to me.

However, at one point I was teaching programming at the university. At that point you realize that C++ is .. huge. It may be fine for me, but is it the right choice for someone starting out?

That said I do love new languages personally. I like to study how they do things. I found that Clojure had nearly the exact concurrency model I prefer to use in C++, and much nicer metaprogramming. As a result, I use it for all web stuff these days.

I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.

Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.

Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.

But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.

C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.

I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.

Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.

Everyone's chief exposure to complexity is the code written in the language, where the complexity comes from the problem domain and everything it takes to wrangle that complexity with what the language has to offer. By that measure, C's sharp limits mean that your exposure to complexity is much greater in a C program than in a C++ program.

If your only measurement is "how many different distinct features are specified by the language", then, well, yes ... C++ is unbeatable for the number of different ways to do one thing.

If the measurement is instead "how much effort is needed to know enough C++ to move from team to team?", then the outlook is bleak for C++. Because the language itself is so huge, everyone uses a different 80% of it.

C++ is hard to use, because to use any of it, you basically have to know all of it, which is a rather large surface area to cover.

Is there another language that requires as much language-knowledge as C++? I can't think of one.

I feel some people love learning new languages, while others just want to get shit done. C++ seems geared towards the latter - I don't (always) want to futz around with a new language, ecosystem, and toolchain when I just want to get something out the door. Programming is a tool, not an end for a lot of people.

Of course c++ isn't the right tool for every job and as each decade passed there are more languages that do certain tasks better.

Yes doing "Hello World" is much easier than C++, however when one actually dives into the ecosystem, programing culture and language improvements since they exist, then it isn't that cut clear to keep skills up to date.

Try to move someone stuck in the ways of Java 7 into a team taking full advantage of Java 16, language, runtime features and libraries.

I poked around with Logo a couple of years ago. It was invented in 1967. It is a dynamic language, and actually pretty good. I remember thinking that there didn't appear to be any obvious deficiencies in the language.

Dylan is also a powerful language, heavily inspired from Lisp, but "without the toenail clippings." It tried it out, but the compiler seemed a bit flakey at the time, so I didn't pursue it much further.

Then there's Pascal. It's very fast to compile, I think chiefly because, unlike C, syntax isn't context-sensitive. Old Pascal suffered from daftness like strings having to be of pre-defined length. It got me to thinking that this might actually be a strength if you're programming microcontrollers. But anyway, this silly restriction was lifted. Pascal is a language that's very easy to get to grips with. C++ wins out over Pascal for application development because it has resource management, not just pointer management (which pascal doesn't have, either).

There's actually a project called Ultibo, which is a "unikernel" for the Raspberry Pi, written in Pascal. You can compile your own kernel using Lazarus. Getting up to speed was pretty straightforward. To mind it had a fatal flaw, though: it had a pre-emptive scheduler, and thus wasn't particularly useful as an RTOS.

What a lot of this illustrates is that anything that can be invented has been invented. Mostly, anyway. The number of programming languages has exploded over the last decade. What do the do - really do - that hasn't been done before?

Here's an idea ... if you want to create a new language, then take a working Pascal, and add your own ingredients. Its syntax is designed to be easily parseable, so you should have a good basis from which to work.

Ada also has it since Ada 95.

So what would this new Pascal like version bring to the table?

The kind of thing I had in mind is for creating Domain Specific Languages - more toy systems than any new earth-shattering paradigm. It's up to the tinkerer. Like, maybe someone wants to add coroutines to the language, for example.

I had one idea in that I'd like to add a nicer way of expressing the parsing of data.

Maybe a Cobol, but nicer. Or a Snobol, but in a more general-purpose language.

Another idea is in the realm of microcontrollers. It could write start-up code for peripherals, and ensure its usage doesn't conflict. I'm not a Rust programmer, but I am aware that it is the kind of problem it addresses.

BUT, the thing about compilers is that a function call is just a function call, it has no idea of intent. By extending the language, you can give the compiler that intent. So certain functions can have compile-time semantics as well as run-time semantics. You could probably achieve the same kind of thing with Lisp.

Anything where one feels the need/desire to extend syntax, basically.

https://www.mikroe.com/mikropascal

https://www.astrobe.com/default.htm

the evidence of all the code not written in C++ and Python suggests the answer is "yes"

In general, a systems language is a great asset in your toolbelt. A high level one can let you shape your own environment to great detail.

In the end I think most systems languages will take you to a similar place. Many others have fewer footguns or better ergonomics than C++. Its distinctive feature/bug is having no opinion of almost anything. Or alternatively, you can find subcommunities with almost any opinion.

Yes absolutely. Once you become familiar with the language the barrier is not that high. Familiarity trumps everything else.

That said, since i am not a Web/mobile developer i had collected some resources to help me learn how to use C++ for Web/Mobile apps, you may find it useful;

https://levelup.gitconnected.com/cross-platform-mobile-and-w...

https://github.com/Microsoft/cpprestsdk

https://medium.com/@ivan.mejia/modern-c-micro-service-implem...

I think for Android development, the NDK support is much better and there you might be able to leverage C++ much easier.

This single phrase has clarified the workings of the C++ standards body like nothing else; When in doubt, add it in!

It's a product of its time, massive success, and a herculean effort to retain backwards compatibility. It can be frustrating at times but I can seem to make great things with it still.

This post has convinced me to look at C++ again. Last time I used it I got put off by the lack of dependency manager so linking things like Boost sucked. Any tips on a modern tool chain?

https://vcpkg.io/en/packages.html

https://conan.io/center/

Plus they can also host binary packages, so you don't have to build the world, just your own stuff.

For some of us that matters.

I looked at random at the "quote" crate on crates.io and, since I've heard of it and it was on that front page, the "abseil" package from vcpkg

First thing I'm wondering is, is this the thing I thought I might need, or did I mishear somebody and I wanted a different thing? Crates.io provides me detailed information about the crate in one click. Yes, this is what I hoped it was, and here's a great description of how to use it. But on vcpkg there's a single line describing Abseil, and it's cut off for some reason with no indication how to read more. Maybe if I paid Microsoft money I'd know? No idea.

OK. Let's use assume we did want this, both are clear here, crates.io gives me the text to add to cargo to use quote in my program, while vcpkg tells me to invoke a slightly awkward command to get abseil, but either would become natural very quickly I'm sure.

Now, we need a bit more information. On crates.io in two clicks I'm looking at programming documentation for quote, explaining how I should use it with working examples. In one more click I'm reading syntax highlighted source code for the actual quote! macro, in case I'm curious how that works. I am suitably horrified, I definitely want somebody else to solve this problem for me.

But on vcpkg after a few moments with no idea I realise that the Octo-cat icon labelled "Star" is a link to a GitHub repo for Abseil, and this seems the only possible way forward. Alas, the GitHub repo also doesn't really document Abseil, but it does eventually produce a link to another third party site about Abseil, and on that site I get told to install Bazel, a build system that Abseil likes so that I can get "started" learning how to use Abseil.

OK, maybe Abseil is special. Not good news, but lets try something different. What does vcpkg have in the way of Hazard Pointers? It suggests libcds. We can again get to a GitHub, which provides us with a (HTTP) link to a doxygen doc site. Clunky but functional, at least it doesn't want me to install separate build tools. I could learn how to use this, although it lacks search and the examples are poor it is serviceable.

But you're right, vcpkg can include binary packages and so you don't have to build the world and if that is all that matters you're onto a winner.

You mention;

>I am average in many but not an expert in one

This is exactly why i am always wary when people give me a long list of languages they "know". They may know the superficial syntax but not the commonly used "idioms" of the language which is what is necessary for fluent expression in the language. This takes time and effort which i would rather spend with a single language and try to truly "master" it as far as possible. The situation is exactly analogous to learning "Natural Languages". You may be fluent in one or a couple while knowing a few introductory phrases/expressions in half a dozen more.

It's kind of a double edged sword...

The latest I've come across is the "R-value lifetime disaster". Arno gave a great talk at cppnow this year [0] highlighting this and Arthur O'Dwyer gave a great rebuttal / follow-up that is also worth considering [1]. The gist of it is that have const& also bind to r values (T&&) causes information about the lifetime to be thrown away. In reality, the "universal binding" ought to have been const&&, as that encodes "can't modify this thing" and "it may not live longer than this function call". This is quite a footgun, but I'm not sure if there's a way to change it with some sort of "language epochs", especially considering that this will have to be exposed in modules / headers so that different "epochs" don't try to link to or use each other's code!

[0] https://www.youtube.com/watch?v=sb7cj-3l1Kc [1] https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetim...

When the compiler can see both the call site and the function definition (such as when the function is inline, or a template) it is free to ignore ABI.

If there is a break, it will either be wholly backward-compatible, so that new code can still call old functions, or be a whole separate build target, like the jump from x86 to amd64, with no possibility of linkage mistakes. (There must be people reading here who don't recall the move from 32- to 64-bit x86. It was wholly painless for programmers; not so much for OS distributors.) Imagine building for ARM today; you are at absolutely no risk of accidentally linking x86 code.

I think Marshall Clow gives a pretty good overview of the ABI issues at a high level [0].

[0] https://www.youtube.com/watch?v=-XjUiLgJE2Y

No one coding modern C++ feels any envy for other languages' GC.

I really enjoy c++, or at least the subset I used for my game last year

But job boards are not the place to look for those.

Not supported; argumentation by mere assertion.

> But job boards are not the place to look for those.

Yeah, we gathered that from the GP. Supporting your argument would require not just repeating where the proof isn't, but showing where it is.

I've focused on C++ and Python, but never used the latter for big projects and even that showed. I had to reach for the docs more, I had to look into idioms or patterns more for Python whereas my C++ flowed.

While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it.

The languages which I've had to learn for specific projects, such as Objective-C, Java or C# have been mostly forgotten. There's a very strong correlation there with the size and length of the project. I think some knowledge is still there and I would be faster to reach competency if I had to use them again, but I would in no way claim to know for example Objective-C now.

Now that I haven't programmed seriously in about two years because of a role change, I can definitely see the impact on my C++ skills: I don't know much about C++17 and up and I've started to find code harder to grasp. Not individual pieces of code, but rather the whole, as if when I step back I no longer have an intuitive grasp about it. I find some language constructs ugly and confusing and no longer feel so attached to C++ or even programming surprisingly enough. Ironically I've been doing some data science stuff in Python, so my skills are pretty much the same there.

I don't like learning programming languages unless I also get something else in return for the time invested. For example I've found an interesting book about systems programming (Rust in Action), so I'll recap my systems programming and also learn some Rust on the side. Pure language books like Programming Rust, even if targeted at C++ programmers and otherwise good do nothing for me. I'd rather learn more about the software/hardware areas I'm interested in.

Stated exactly like that, yes, that's probably not a good idea.

Stated like "learning new programming languages that are significantly different than the ones you already know is unconditionally good" - that's very close to truth.

The languages you named are Objective-C, C++, Java, C#, and Python. From my perspective, those languages are so similar as to be almost the same.

Learning Red, Io, (a) Lisp, Prolog, Smalltalk, Curry, TLA+, Coq/Lean (or any other theorem prover, actually), Erlang, or (a) FORTH will actually give you an experience that's significantly different than anything else you've used before, with accompanying new ways of thinking that you can apply to your other languages and projects.

Concepts, Techniques, and Models of Computer Programming [1] with Mozart/Oz covers a lot of ground by itself.

[1] https://www.goodreads.com/book/show/772585.Concepts_Techniqu...

Programming languages are table stakes and they compete for attention with the things which do matter in a project, like the social aspects and project management, team skills, development ecosystem and domain knowledge among others. Having for example deep knowledge the kernel would be more useful to me than all of the languages in your list combined.

>While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it

Very true. I am always mystified when people tell me that i should be able to "pick up" a new language in a couple of weeks. I find learning even a so-called "easy" language like Python somewhat "difficult". Unless i read/write a lot of Python code there is no way i can get fluent in it to feel comfortable with it.

My biggest issue with C++ is that although it does seem to be adding lots of good quality of life changes with the recent standards for developers it has inherit flaws that without breaking backwards compatibility it can never be as safe as Rust. And I think C++ is probably right to not break backwards compatibility, it has too large of a user base that will most likely splinter, it reminds me of the python 2/3 problems.

At this point, it appears that Rust could well survive and become a mainstream language, eventually, but that is by no means assured. While that puts it well ahead of any other language created in this millennium, it is very far from ready to raise a family on.

Remember, Ada had far more investment and industry backing than Rust will have for a long time to come, but was wiped out. Fighter planes are coded in C++, not Ada.

https://www.adacore.com/customers/eurofighter-typhoon https://www.adacore.com/customers/amx-modernization-program https://www.adacore.com/customers/arinc-653 https://www.adacore.com/company/our-customers

Rust is used by, and financially supported by, many of the learning companies in the technology industry: Microsoft, Google, Facebook, AWS, Dropbox, and others. It's being piloted for use in the Linux kernel and is already accepted into Android.

Unlike Ada, its development was never bootstrapped by public funds and so all of its growth is due to its practical benefits.

I don't know why fighter planes are the standard to reach, but Rust is even being used in aerospace: both Rocketlab and SpaceX have made public statements supporting Rust or are hiring people with Rust expertise.

"Used by <Big Company>" means much, much less than most people who mention it believe. The bigger the company, the more likely it is that they use literally anything at all you can think of, and the correspondingly less it means that they do. They might even be using it in a certain project deemed strategic. But we all know how many of even "strategic" projects at big companies end up canceled, even when they seemed to be a success. You can be certain that they are not using it for anything central to how the company makes its money.

It is more interesting when a $company uses $newtech where it will only have an income if the project succeeds. But you probably never heard of $company, otherwise, so have no way to evaluate how important it is.

SpaceX has said publicly it uses C++ for mission-critical work. Like other $billions companies, they do a lot of things. Saying they do Rust, too, makes them seem edgy in circles where people are likely to hear about it, regardless of how much they actually depend on it. So it is really hard to tell.

TL;DR: I think it's not healthy for a language to try to do everything.

PS: Learning and regularly using other languages also feeds back improvements into my C and C++ coding.

/s (in case anyone couldn't tell...)