Time will tell.

Only like 1% of people actually write on the internet. The everyone's doing it argument seems to me, more like a vocal minority.

Both the US Federal Government and the EU are apparently in the "vocal minority" who think programmers should stop using C++ because it's unsafe. Both have created documents which more or less just outright say that over the past year or so.

As a result, two other very significant things have happened which might reasonably cause people to decide that for C++ this is perhaps the beginning of the end rather than just an interesting bump in the road.

1. Several people or groups announced "successor languages" in 2022. Unlike Rust, these aren't merely languages which are sometimes cited as potential safer alternatives to C++ or as languages you might choose instead, yet have an existence all their own - The successor languages are specifically targeting C++ and C++ programmers. In this number we can count Carbon, Val, Circle and Cpp2 / CppFront.

2. Several WG21 ("The C++ Standards Committee") members wrote papers for WG21 either claiming that there's no problem (this is not, in fact, a thing you do when there's no problem, nobody writes US policy papers saying the US is not at risk of attack by Belgium) or offering vague plans for plans to do something about the problem. These are hastily written (Bjarne Stroustrup wrote or co-wrote four of them in as many months, all with numerous typographical errors) and do not in my view make a case that C++ is or will be fine although that's how they're intended.

New developers and young people are not choosing C++ as a language these days. Rust is 'hot' and has much more mindshare even if it's not being used in large enterprises much yet.

What are the demographics of the developers you talk to? That may clear up your confusion.

It's also part of fuchsia which is shipping in all those nest devices. I wonder when folks will decide it's really "made it".

In order to just compile a single Hello world program, you need to install the standead library, a linker and a compiler, each with their own version.

There is too many ways that compilation could fall, and fixing them requires extensive knowledge about different aspects, like how linker works, how is C++ standardized, etc.

The error message you got is really unhelpful. Missing a virtual keyword in a destructor, and you got a few hundred lines of error message and none of them mentioned "virtual". Segment fault is hard to trace because you do not have any error message at all.

Rust is just a lot simpler because it remove/abstract away lots of complexity. Just install Rust with rustup and it will just work. Error message is pretty helpful too.

Name the last green field Cobol development however.

But in government and very large businesses (banks, insurance companies, airlines) I would not be surprised at all if there was still greenfield COBOL work done. Just not nearly as much as say in the mid 80's.

If they truly have a green field to develop on, nobody will pick COBOL.

Yes, modern C++ may be pretty good, but how many people actually get to write it instead of sticking with the tried and true ye olde versions actually in the codebase.

Existing projects for sure

New projects from scratch reaching for C++ off the shelf? Probably just video games maybe?

Serious business obviously still writes in C++ more than rust and so it isn't legacy, but I can see why somebody may not be excited about spending their free time writing C++, and so Rust is the better choice if it gets people excited to contribute.

They are out there, though the "in Rust" is part of the footnote usually.

I interviewed recently for a 350k+ job involving rust and the odd thing about it was that I'm an okay C++ programmer, but I'm about as good as the average rust programmer because it's not been popular for that long.

Nobody is asking for a decade+ experience on rust, only that you don't run away from it when you hit compilation fights with the borrow checker.

This is not just about Rust though, but because I'm a second systems sort of engineer who can go in replace an aging C++ platform slowly by rewriting bits of it or modularizing it as we go. And the pay matches how badly they want to tear out the tech debt in the rewrite pass (also how horrible it will be for the first 8-10 months).

This comment induces a sort of cognitive dissonance in me. Rust is in the Linux kernel, and Firefox. How are LLVM and WebKit different? Of course, Rust may not displace C++ everywhere. Is that what you were saying?

If anything, I'd think a browser is prime real estate for Rust, where the security guarantees are just that much more important.

Rust was created at Mozilla to help with browser engine development, so it’s not totally shocking that it’s in Firefox.

Rust is in the Linux kernel in the sense that its build system can compile interoperable Rust code. But the kernel is big — it’s 30 years of C code written by thousands of contributors which receives dozens of patches (in C) per day. Obviously “Rust in the kernel” has to start somewhere, but as of today, it’s really only relevant to Rust people who evangelize it. A kernel developer who doesn’t read HN would probably have no idea that Rust support was added.

Going back to the OP, the claim that C++ is “becoming a legacy language” is…bold. IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in market share by alternatives written in Rust. If all of the biggest systems software projects in the world are still mostly written in C/C++ and still receive almost all of their contributions in C/C++, claiming that Rust is bumping those languages to some “legacy” tier is ridiculous. Things might go that way in the future, but we definitely aren’t there yet.

Given this super high bar, I'm not sure any language would fit the mold of "legacy". I could just as easily say COBOL isn't legacy given this standard, as the world has not chosen to rewrite most of its COBOL software in Java yet, although we tend to think of COBOL as the legacy language.

So I disagree with your definition of "legacy". "Not considered for greenfield development" seems like a better definition of legacy to me.

So, yes, the term "legacy" for C/C++ would seem a little heavy handed for all software domains. But, for the software domain `fish` is targeting, it's not a ridiculous claim. Lots of the new, interesting stuff happening in systems-y, tools-y CLI stuff is happening in Rust. That isn't to say all of it is, or C/C++ isn't used ever, but if the OP said, "Look at the trajectory", and "Can you imagine writing a new shell in C or C++ in 10 years?", I might have to agree. Or, more concretely, if the OP said, "I personally can't imagine writing my open source software CLI tool in C or C++ in 10 years", I would definitely agree.

But also look into the future: if someone is currently writing very first lines of a project that will become equally big in a decade or two, that may likely be in Rust, not C++.

People do the C/Rust comparison, but at least C has a simpler mental model so is a different thing. I feel like C++ has similar, if not more, complexity to Rust and is harder to onboard.

I do think there are domains where "let's use Rust" are a bit ... aspirational more than anything (anything related to graphics or OS integration...). And there C++ makes a lot of sense. But I think that day by day the number of projects where C++ is the only obvious choice goes down. Hell, it's been going down since Java!

Maybe I'm just one of those spoiled younger developers who expects great DX on all my tools, but it makes me really reluctant to invest more time into learning C++ when I could be contributing to open source Rust and improving the ecosystem. Getting better with C++ just feels like learning an endless series of sharp edges.

They are adopting Rust in some small spots like Azure Sphere, and Rust/WinRT, yet WinDev, XBox, Office, .NET (for the runtime), DirectX aren't getting rid of their C++ code anytime soon.

Rust experience is compeling if one doesn't need to rewrite the world, e.g. doing CUDA in C++ versus Rust.

Of course it's sticky- someone who's already an expert in the miserable language may not choose to totally re-skill themselves (and anyway, once you know something that well it tends to become less miserable). But the new generations will heavily favor the thing that's welcoming to them, not the thing that's prickly

Which part of the following example is hard:

program(mynewproject LANGUAGES CXX)

add_library(libfoo STATIC foo.cpp )

add_executable(bar bar.cpp main.cpp )

target_link_libraries(bar libfoo )

Edit: and this message was downvoted? Seriously?

Differently put: a phrase "metabuild system" has both a lexical sense and an idealized sense. The lexical sense would be something that generates an input to build systems. The idealized sense would be something that does everything else not possible or difficult in build systems. CMake was definitely far from that ideal [1]; it was often simpler to make a configure script in your favorite language (and, for god's sake, not in M4) than using CMake.

[1] Was using a present tense but edited after realizing that I don't know much about recent changes to CMake. Still enough to justify my (and others') criticism.

Not really. When people talk about setting up a new project, they talk about starting a hello world project and build up from there.

Anyway, I'll bite. What would it take to add a dependency? If it exports a cmake config file which exports targets, all it takes is this:

find_package(MyDependency),

target_link_libraries(bar MyDependency::targetA MyDependency::targetB ... MyDependency::targetZ )

If it doesn't and it is instead a system library then you can even pass the library instead.

add_library(bar systemlibrary )

If the library exports no cmake config and you have anything exotic you can put together your own cmake find modules, and proceed to follow step A.

Alternatively, you can even bolt on something like Conan and just follow step A all the time.

> Differently put: a phrase "metabuild system" has (...)

Sorry, but do you actually have any concrete example of any difficulty setting up a C++ project?

The original reply said one dabbled C++ via "creative coding, graphics programming, etc.", which definitely needs dependencies from the beginning. Can you draw a nicely shaded triangle only with the C++ standard library?

> If the library exports no cmake config and you have anything exotic you can put together your own cmake find modules, and proceed to follow step A.

They are not exotic, libraries without cmake config are common. So, as I've said before, people had to come up with their own find modules and this requires lots of trial and error to get it right. Guaranteed, it might have been possible to collect those into some sort of registry (a la DefinitelyTyped for TypeScript .d.ts files), and probably something like Conan can provide that, but ideally that should have been built into CMake. And keep in mind that Cargo---something we were comparing against back in time---does all of them declaratively. (Arguably, from users' perspective, it can handle C/C++ dependencies better than CMake!)

Taken straight from Qt's page on OpenGL support:

find_package(Qt6 REQUIRED COMPONENTS OpenGL) target_link_libraries(mytarget PRIVATE Qt6::OpenGL)

https://doc.qt.io/qt-6/qtopengl-index.html

Do you feel this is too hard to setup?

[1] https://github.com/qt/qtbase/tree/dev/cmake

It's not Qt6. The same goes for Qt5, which has been around for what, close to a decade?

And what's your point, exactly? That things are hard if you purposedly ignore all the examples that prove that things are patently easy and trivial? Because it seems evident to me that if you want to quickly setup a C++ project to try out stuff, a CMake project with single-digit lines of code that get you a window with an OpenGL context going is right what you'd be looking for.

But instead you complain that the choice of build system and framework made things easy? And that's why things are not hard

What exactly do you think is your point?

I have no doubt that people who work on big commercial C++ project have sensible build systems and documentation that's not too hard. But it's incredibly common when working in this art/graphics space to need to try to get someone's bitrotted random project without docs or build system running. Common to have to do that AND have to do it on another platform.

That said... Rust and OpenGL have quite an impedance mismatch, don't they?

The options are there to be used.

Take a look: https://stackoverflow.com/questions/75270938/thread-pool-wit...

Options that are barely supported, severely limited in features, are only reasonable for tiny side projects, etc.

If your project doesn't take long to compile or test anyways.... I can see getting annoyed.

I have to call bullshit on this claim.

CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.

What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.

You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.

To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.

Nothing beats a language's own dedicated packaging system (yes, even python's mess is better than bazel+python) but C++ and Java have bad build systems, so bazel is better for them

What is wrong with Maven or Gradle?

But in a corporate environment where repositories are often authenticated, the fact that dependency fetch issues are reported as Java exceptions (having the wrong password in your netrc file shows up as "IOException occurred during fetch of ... Code 401") is a deal breaker for a C/C++ development staff unfamiliar with Java.

They happily take their ten minute incremental builds and "it works on my machine" issues in return for a build process they can understand, and as much as I want them to be wrong (I use Bazel all the time at home), I can't blame them for wanting tooling they understand.

Compared to what? Modern C++ is by far the most expressive systems language. That is its primary selling point. It isn’t pretty but it is uniquely powerful. One of the reasons C++ isn’t disappearing any time soon is that it elegantly and efficiently handles some software design problems that Rust struggles with. Rust and C++ are optimized for different types of software.

As is implied, the type of software someone is writing has a large impact on whether or not they need the expressiveness of C++.

If you want to iterate over a range of integers, you need to manually explain to the computer how to do it. In 2023. Also, you need to Write Everything Twice because of the ancient header system.

Modules are not supported by most compilers (in g++ you have to enable them as an experimental feature with -fmodules-ts, and if you want to import the standard library as modules, you need to pre-compile them into your project directory with some arcane commands).

Modules: GCC and clang will eventually get there, I am already enjoying them on VC++

    #define RANGE(type, name, last) type name = 0, last__ = (last); name != last__; name++

    for (RANGE(i32, i, foo->count))
        ...

Once you you've worked enough with proper enums and matches, that's the first thing you'll be lacking in C++ (and no, std::variant is a horrible mess without proper syntax support and doesn't even get close).

C++ has lots of problems, lack of expressiveness isn't one of them.

I feel that you are the very first person ever making such a statement. Can you provide what's your single best example showing C++'s inexpressiveness and "high impedance with cognition"?

I've been working with C++ for a few years and did some work porting legacy apps to CMake. I've saw awful CMake legacy projects but since CMake 3.0 and the introduction of it's declarative way of setting up targets CMake is actually quite nice to work with.

What exactly does CMake do that you feel is "an ancient horrible mess"? Can you provide any specific example?

There is build2[1], which tries to approximate Cargo's experience for C/C++ projects while providing more depth, especially in the build system (unfortunately the "build by convention" ship has sailed for C/C++ so there needs to be some flexibility).

As some indication of the project's "seriousness" (there are a lot of toy build systems out there), it builds Boost and Qt (both 5 and 6 but only classic for now).

[1] https://build2.org

Rather marginalized but https://waf.io/

All of it seems to be based on copying dependencies around or installing them on a system level. Plus mostly template/text driven make files.

I'm still not sure if this is really how C++ is developed.

Four years ago, when I last looked, I wasn't able to find a good resource for people with my background to learn C++ the ecosystem (not the language).

That turned me to Rust. All of this text to give strong support for your first paragraph.

There's no way it's legacy.

Rust might attract new devs to the project, sure. But at the same time, quality software mature developers work diligently with the tools and frameworks they have and improve things iteratively rather than trying to burn down and rebuild everything.

And rewrites in general, no matter the language, are on the whole dangerous and harmful ventures that usually lead to trouble. As per the classic Spolsky essay.

I’ve done these kinds of ports before. After you get used to it, you can almost shut your brain off and just start copying lines (so long as the languages are similar).

While Rust is still too young to make C++ a legacy alone, the transition has been long underway. "Scripting" languages, managed language runtimes, and a popularity of web development has greatly reduced needs for C++. Nowadays no one writes a web server in C++ [1], not because it is not performant enough for its job, but because other languages are better suited to provide a tradeoff between development experience and performance. C++ will continue to have lots of niches for coming decades, but is already a legacy in many enough fields.

[1] Well, not really! First and foremost I have written a C++ web server as late as in 2016. But we needed a very good reason to do so, and any further logic was delegated to C#.

The way I am seeing it shake out is that C++ is used for the core and Rust is used for skins and interfaces around the C++ core. It plays to their strengths to some extent.

That's an interesting statement. While you can most definitely write systems in C++ and Rust, they really start to excel when you are in the lower layers of the stack where many other languages start to fall short. What is the significance of calling attention to systems development in particular?

Anyway, C++ is just getting new features every 3 years—these features are often really great additions, but they’re limited by compatibility with existing features (they’re not the best they could be) and not having legacy features in the first place is an enormous and overlooked value proposition.

it's still dominating and gaining.

> but they’re limited by compatibility with existing feature

no, they deprecate features as well. this is why the auto keyword of pre-c++11 doesn't work anymore

> Most of the popular measures basically measures noise and ought to report their findings in decibel rather than "popularity." [1]

I believe he is wise enough to not change his opinion when TIOBE designated C++ as the Programming Language of the Year 2022 (which would mean, borrowing his words, C++ somehow kept making lots of noise).

[1] https://stroustrup.com/bs_faq.html#decline

https://blog.nindalf.com/posts/stop-citing-tiobe/

I see you didn't actually read the link I pasted, especially not the section "Evaluating languages for projects". There's several possible ways you can compare (StackOverflow survey, JetBrains survey, GitHub PRs, StackOverflow trends, Google trends) but ultimately it comes down to what's a good fit for your project.

- Can developers be hired/trained to use it?

- Will they be happy using it?

- What will our development velocity be on this language? What will be the operational burden of keeping it running in production?

- Do we need to rely on third party code? Does that code already exist and what is its quality?

Only your team can answer these questions for your project in particular. It depends on your business problem, your local jobs market, your engineering budget.

I didn't make the claim that C++ is losing popularity, but I did mention some sources that do. These are marginal, not dramatic declines. Certainly not a terminal decline.

- Number of people searching Google - https://trends.google.com/trends/explore?date=2012-07-31%202...

- Number of questions asked on StackOverflow that month - https://insights.stackoverflow.com/trends?tags=java%2Cc%2B%2...

A far cry from the claim that it's "dominating and gaining", as you said.

FWIW, I've been a professional C++ programmer, and I like C++.

Below the list a graph showing the ratings over a 20 year period is provided. It shows C++ declining until about ~2017 but recently starting rising again.

https://blog.nindalf.com/posts/stop-citing-tiobe/

> TIOBE has +/- 50% error margin and even if the data wasn’t unusable, it’s misrepresented (measuring mentions picked by search engine algorithms over a historical corpus, not just current year, not actual usage). It’s so bad that I think it’s wrong to even mention it with “a grain of salt”. It’s a developer’s horoscope.

> TIOBE thinks C popularity has halved one year and tripled next year. It thinks a niche db query language from a commercial product discontinued in 2007 is more popular in 2023 than TypeScript. I can’t emphasize enough how garbage this data is, even the top 10. It requires overlooking so many grave errors that it exists only to reinforce preexisting beliefs.

Cobol is legacy compared with C++, when C++ was new. You can see it immediately, the new language is just better than the old one, the writing is on the wall. All of the arguments for C++ boil down to path dependence ("We have X million lines in it", "obscure platform X isn't supported by clang", etc) there aren't good arguments for a new project to pick C++ over Rust.

So it's legacy because Rust dominates C++. It will take time for that to play out and for the amount of code in rust to exceed the amount written in C++, but it's true.

(There's an additional argument one might make that Rust is a niche language that won't gain traction, but we're far past the point where that argument can be taken seriously, with Rust in the Linux kernel, and Amazon, Google and Microsoft all adopting it)

They are hype-driven cargo-cultists who embody the role of hype-driven fanboys mindlessly pushing a hyped technology.

No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.

The most pressing problem plaguing Rust is it's community and it's extensive use of ignorant and/or bad faith claims to upsell Rust while criticising technologies they know nothing about. Most of the people they are trying to pull these stunts are professional software developers with years of experience. Perhaps some of them know a thing or two about the technologies they've been using? Why does the Rust community think these stunts work in their favour?

All language communities care about their language. It boggles the mind how anyone could imply that only Rust cares about this stuff.

The Rust community is renowned for being problematic. Time and again it's called out on the grief it creates.

I don't even believe you think this is true. People who recommended Rust are generally positive.

Sure, sometimes it's compared to other languages and ecosystems, but that's usually done to point out improvements it has over other languages people are familiar with (I think that's just to describe).

For example, I could talk in a void how I like that the packaging and build system are more cohesive and simple, but it will be a long essay as to why, and ring differently to different audiences. An TypeScript, Ruby and Python developer will not be interested, since they've always had those. But comparing it to C/C++ build systems makes more sense, because the languages occupy the same domain.

There's other examples I could give with regards to the type system, etc. So, it's not there for me to tell you "why C++ sucks" but to easier demonstrate to you what improvements would make your job easier and more enjoyable. Some people disagree, and you do too, and that's fine.

If you say you disagreed because X, people will respond, though. They will either think you're trying to misconstruct the narrative (like I feel you did in this comment, but I apologise if that's not true), or think you have a misunderstanding or a misconception and want to clarify what they said. So, it's not an attack, it's just Internet comment etiquette.

The point was never to put C/C++ down, just to make it easier to illustrate the improvements. People have always complaining and disliked the accidentally complexity of C++; it's got nothing to do with Rust. The only difference now is that there's an alternative.

Or another thing, which could be purely anecdotal: I've worked on C++ codebases and Rust codebases both in private and professionally, and even though I have more experience with C++, I'm generally more confident when working with Rust. Probably because I'm less "vigilant" of certain types of bugs due to the more modern type system.

None of this is to say that Rust doesn't have its own problems, because it certainly does

https://crates.io/search?q=lock-free

Or this this use case considered legacy now?

C++ is really unpleasant if you want to hop-in into some project. External dependencies (in most cases manually handled), various build systems (including custom ones - every project I worked on used a different build system!), various standards - ex. we have C++23 around the corner, and Fish has stayed on C++11. If you work in C++ you will stumble upon code from C++11 (or even earlier) to C++17. Learning C++ with intention to work in it means you need to basically know every standard released.

I don't think anyone should learn C++ nowadays if they don't have too - the only exception is if you are really interested in the industry that mainly use C++ and it doesn't seem it will change.

For a hobby or side project, though? You just do what is interesting and fun, and maybe working with new languages is fun to a lot of people. This could account for the (perceived) difficulty in finding c++ contributors, despite the prevalence of c++ in existing code bases.

But in the professional industry, C++ is still alive and strong. Lots of professionals are comfortable with C++ and don't want to ear about Rust or anything else. All my customers paying money are using C++. Even for new projects.

That said, I can see a growing interest for Rust in the industry as well. So this might change really soon