> Where are all the C++ programmers? People are seemingly scared away from the language by a terrible stigma: the notion that it is a legacy program.
I think this is because the pool of jobs for C++ programmers is so small.
I took a position as a web dev at a company whose main product was a CAD application. Most of my work was in NodeJS, but occasionally, I'd have to dip into the C/C++ layer to make some API changes to facilitate my JS development. When my project was cancelled, I was given the option to move to a team doing all C++ development for the desktop app. I gave it some thought and realized that this was probably the only company within 100 miles who needed C++ developers, and that most of the people I worked with were hired out of college.
I left immediate afterwards. I didn't want to be stuck in my 40s-50s with a unless skillset and have to start back from the beginning. I'm sure other people considering fintech work feel similarly. We live in a world where people keep their jobs for 2-5 years, meaning we live in a world where workers need to consider the needs of the entire job market, not the needs of an individual company.
> I didn't want to be stuck in my 40s-50s with a unless skillset and have to start back from the beginning.
This is absolutely nonsensical. In 20 years no one will remember about NodeJS (or it will not be the mainstream tool for web dev), but the C++ CAD application will definitely still be here, in both use and active development, and it will very likely still be in C++.
Just think about it. The last C++ CAD application I worked in was started in 1987. In 2023 it was still C++, and not only still sellable, but also incredibly profitable. They are practically a monopoly in their target market. A market which is highly likely to continue to exist for the next century or so.
How did NodeJS look like in 1987 ? A single skillset that can carry for 30years+ in computing is _nothing_ to scoff at.
You're conflating runtime and language. I doubt JS or TS will go away anytime soon, seeing as they power the Web. Sure, there will be ways to augment them and the languages evolved since what they used to be, but I don't think they'll "die"
> I doubt JS or TS will go away anytime soon, seeing as they power the Web.
We have a Javascript interpreter orbiting around the L2 Lagrange point.[1] Safe to say that will remain there even if our culture down here on Earth collapses.
As far as cultural artefacts go that one will probably survive all of us.
I am not conflating, just replying to OP. Anyway, even if you do want to talk about web dev in general... how did web dev look in 1987, again?
The mere fact that you are listing languages that are only a decade or so old in your statement should be a rather large hint that web development is a much faster moving target, and highly unlikely to still be recognizable in a couple decades.
Some technologies, even if they are popular today, die a death of slow attrition. There may be demand, but it's niche (like COBOL today).
C (and C++) will remain popular for a longer time for a number of reasons; after all, under the hood NodeJS is a C program right? Because it's the most useful portable macro assembler anybody has invented, and it forms the basis of nearly every higher-level system.
In the context of this discussion Perl is an exception that proves the rule.
There are no Perl jobs because Perl was supplanted by Python and Ruby and embarked on a disastrous Perl 6 journey.
This will not happen to node.
JavaScript is and will continue to be for the next 10 years the most popular programming language ("popular" == "most jobs") because it has monopoly in the browser.
As a result JavaScript will continue to be used in other domains (backend, desktop, mobile) due to sheer number of JavaScript programmers. Quantity is a quality of its own.
So node (and deno and bun) will continue to be used and there will be plenty of jobs for JavaScript programmers ("node" programmer is 90% JavaScript programmer and 10% "node specific APIs" programmer).
Of all programming languages that you worry might disappear in the future, JavaScript is at the end of the list.
To be clear, my thought process was something like this:
I have useful skills that I can use to leverage into another job right now. In a year, those skills will be slightly irrelevant, in two years, those skills will be very irrelevant, etc. Basically, the longer I stayed there, the less likely I was to be able to get another job based on my current skillset.
Three jobs later, I don't do NodeJS development anymore. I leveraged my skillset to get a GCP consulting gig and now I work for a startup where I use my expertise to get new products off the ground.
If I decided to leave tomorrow, I have 1000x more job opportunities as a GCP consultant than I would as a C++ developer. My goal is to keep learning the tools that will give me the best job opportunities.
Some people want to be experts in a niche area. But I want to have the most job opportunities available to me. One is not better than the other, but I think more people share my outlook. A new developer today could make an entire career out of doing PHP development for the next 30 years, but would that be an advisable choice of action?
C++ is here for longer than your career will last. Outside of HN/Web bubbles it's still used everywhere. Chances are you're writing this message on a C/C++ OS running a C/C++ browser engine. NodeJS and v8 are C++ applications.
I went to a lecture by Stroustrup once who was asked what he thought of Java and jokingly said he didn't like to be negative about C++ applications. While this is a joke and Java isn't actually written in C++ (anymore?), it's good to remember the majority of the stack under yours is probably in it.
> Chances are you're writing this message on a C/C++ OS running a C/C++ browser engine. NodeJS and v8 are C++ applications.
That's because there was hardly any mainstream alternatives (sans C, I guess) within its domains (ie systems programming and related field) until recently. That's not to say people haven't wished for alternatives. God knows I have
I've only worked in tech for a decade but I remember seeing this back then, and can find articles two decades ago about the same thing. There's just so much code in C++ that can't be re-written or can be re-written but will take hundreds of developer years. For example Rust doesn't even have a spec. I don't think I could use Rust for regulated healthcare/defense fields? There's not really that much support in hardware for Rust in robotics. If something works in banking why risk moving to Rust? Etc... I think Rust has a place but right now I'd wager a C++ code base is worked on way after the last Rust code base has been created.
Right, you're absolutely correct that C++ is currently the defacto standard (or maybe not even just defacto) in those fields.
I have a lot of opinions on the situation. Some are on technical merits, some boil down to humans doing human things.
It's difficult for me to give C++ much credit on that front due to the fact it's had such an incredibly long head start and tremendous amount of effort put into it. Similar efforts exist for Rust now, but they're only starting.
Maybe something better than Rust comes along eventually too. I'm not married to Rust. That doesn't mean I'll want Rust to fail or disappear. It just means there will be more choices.
I'm just not going to let my tools hold me back. Same goes for the C++ and Rust situation currently.
Also, it's possible that it's just a quirk of preference. Some people prefer mangoes to pineapple, some are the opposite.
There have been a million things hyped as alternatives, and even though it is very easy to argue retrospectively that they were not really alternatives, they definitely were hyped as much or even more than e.g. Rust is hyped these days.
think Java and Go. I have already _lived_ an era where I thought C++ would eventually be replaced with Java and I would have to learn Java (this was so long ago). The effect was so pervasive that e.g. universities started teaching Java instead of C as their introductory language. Why would anyone want to manage memory manually, ever again? Benchmarks were showing Java as beating C++ in some algorithms, and theoretical papers appeared about how some kind of programs are much easier to optimize for JIT VMs than classical compilers. Everyone thought it was just a matter of time until classical compiled languages were irrelevant. Even in the embedded space (and Java made significant inroads). The effect was so big I was actually convinced to start up learning Java ... only for C++ to eventually prevail over Java.
The last time this happened was with Go. Every single week there would be an article here in HN about Go this and Go that, or how Google is rewritting their C/C++ codebases into Go. Turns out, they did not. You then start to hear retroactive justifications about how Go was actually a "services" language instead of a C replacement (despite the fact it was literally sold as a C replacement made by the creators of C itself no less).
Nowadays we get articles about Google rewriting their codebases into Rust.
What? Java dominates C++ in number of professional programmers. It totally ate C++'s lunch. Meanwhile, universities teach Java, C, Python, and a bit of Scheme if they're feeling spicy.
Look, I'm not saying C++ will go away. I agree with you the whole "X will be the Y killer" arguments are nonsense.
I used to like C++, and just don't care about it any more. It can stay, and I'm sure it makes people happy to use it if that's all they know. It's just that it mostly made me miserable—even though I reached for it for years.
Right now people have more choices, some of which you mentioned. Is Go a better choice than C++ for some projects? Absolutely! Can it be worse? Absolutely! Theses things depend on so many things.
Same goes for Java, and Rust, and TypeScript, Haskell.
The whole "C++ can do everything those languages can do" is just a nonsensical argument. C can do everything C++ can, so what? I can come up with more ludicrous examples of that statement too.
Tl;Dr if C++ tickles someone the right way: I'm happy for them to use it. But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
No one is saying that . C++ will obviously never go away, the same way that APL will never go away. But what is questioned here is whether it will actually be a _relevant_ skill in future times to come.
To simply say "it will be yet another tool!" is just a value-less assertion.
> But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
Who is doing that, either?
My personal opinion is that the language who eventually becomes most relevant will be the one with the _fewest_ PL advancements, and that will be a sad thing, but is life as usual. Or what was popularly considered a PL advancement last decade will just be seen as a side step in the next. Again, the usual...
> > But shunning any conversation about PL advancements because alternatives have them and C++ doesn't is immature and unproductive.
>
> Who is doing that, either?
Unfortunately many. You can even see these comments on HN.
Sometimes people even get angry over the whole RIIR stuff, or if Rust gets introduced into a codebase, and the project moves away from C++. It's like they ignore the listed reasonings the maintainer explained completely.
Or when people speak about memory safety people pivot it into a general security conversation, ignoring the merits of the borrowing system.
If you speak of the benefits of Rust enums (or Algebraic data types in general sometimes, sadly) it gets called "glorified tagged enums" (or syntactic sugar for them).
People saying "well boost has a library for that" and talking about beast asio to compare it to Rust async, etc.
Or saying C++ can do have the same or similar value ownerships semantic through shared_ptr/unique_ptr when that's simply not true.
Or when people say "well standard library uses unsafe" (without even knowing what "unsafe" in Rust means, I might add)
Uh there's so many other misconstructions or misconceptions that I've seen, but I don't go around collecting them so I can't really remember more from the top of my head.
Look at the Chromium discussion when the devs decided to introduce Rust, or the recent Fish shell announcement, or when Linux decided to add Rust. Full of "but C++..." shills who haven't even contributed to the projects
> My personal opinion is that the language who eventually becomes most relevant will be the one with the _fewest_ PL advancements, and that will be a sad thing, but is life as usual. Or what was popularly considered a PL advancement last decade will just be seen as a side step in the next. Again, the usual...
I disagree because I think nature (and humans) seek to reduce the amount of energy spent on activities for desired outcomes. Ie, we want to optimise the process, and we are lazy. Rust saves me mental and emotional energy. Since changing jobs (from C++ to Rust) by burnout has been recovering and I'm feeling more energised after work too. And the current job is arguably more straining as it has more responsibility. I don't think Rust is quite there yet either, but it feels like a step in the right direction.
> C++ is here for longer than your career will last.
How many C++ jobs are there currently compared to, for example, NodeJS? 1000:1? 10,000:1? I have no idea, but I do know that there are very, very few c++ opportunities in the midwest.
As in engineering, careers are about trade-offs: we can go deep into a tech to make us very qualified for a narrow sub-set of jobs; or we can go broad and be less qualified for a wider selection of jobs. I've decided that broad, shallow skills are more useful than deep, narrow skill sets.
I think the poor availability of C++ jobs is what keeps people from focusing on it as a career, and I was providing a personal anecdote to express that idea. While the software I'm using to write this message may be written in C++, the company who owns the software I'm using to write this message isn't going to hire me.
Worked at cruise line company many years ago that had some IBM mainframe developers who I think used COBOL as the programming platform. Given my preconceptions that few engineers had COBOL skills, I assumed that there were making big $'s in this niche market. Found out it was like 50 dollars an hour which was significantly less that I was getting as an enterprise java dev. Asked one of them why the comp was so low and they said its was because there was still allot of graybearded COBOL devs around and fewer opportunities.
There's this mindset that you have to avoid finding a niche, because you're limiting your options.
Being a perfect fullstack devops generalist is like fishing in the ocean with trillions of fish, while having a niche is more like just shooting fish in a barrel.
You don't need an unlimited supply of jobs. You just need one job, and specializing in something puts you in a good position to find one.
I think this is because the pool of jobs for C++ programmers is so small.
I took a position as a web dev at a company whose main product was a CAD application. Most of my work was in NodeJS, but occasionally, I'd have to dip into the C/C++ layer to make some API changes to facilitate my JS development. When my project was cancelled, I was given the option to move to a team doing all C++ development for the desktop app. I gave it some thought and realized that this was probably the only company within 100 miles who needed C++ developers, and that most of the people I worked with were hired out of college.
I left immediate afterwards. I didn't want to be stuck in my 40s-50s with a unless skillset and have to start back from the beginning. I'm sure other people considering fintech work feel similarly. We live in a world where people keep their jobs for 2-5 years, meaning we live in a world where workers need to consider the needs of the entire job market, not the needs of an individual company.