These are financial firms griping about the lack of developers. They're some of the highest paid developers in the world. But working for these companies is also insanely stressful. Long hours, high pressure.
The best thing they could do to attract talent would be to offer a choice of 3, 4 or 5 days for 60%, 80% or 100% salary. Many people would probably choose 3 days at a high paying finance job over 5 days somewhere else and 60% of the money they tend to offer at those companies would still be really good money.
The glue code is C++ still. It's also a much less glamorous job than when the C++ programmers were the "hot shit" instead of the people who specialized in accelerators.
So they are complaining that they can't find people who want to be second class citizens while still dealing with the pressure and hours using language skills they acknowledge are in high demand...
Yeah, kinda, CUDA is c++ that I can't run cppcheck or clang tidy on, and the important bits are either calls into the cu* libraries which are c style, or kernels, which are really their own thing.
Yes, kernel code is GPU style rather than CPU style.
But the CPU-drivers of CUDA are all C++. Albeit a C-like API (cudaMalloc, lol), but its a clang compiler for the CPU code nonetheless. If you have complex GPU + CPU interactions, you'll need to be a C++ expert.
Even if you aren't doing GPU work and sticking "only" with CPU-side CUDA, its all C++.
Last time I looked at the finance industry, which was admittedly a while ago, I saw a C++ job that listed the salary as being around $100k. Sounds reasonable.
In New York City. Oh.
Compare to Google salaries, on levels.fyi for example. I know they're not theoretical or inaccurate because I worked at Google for a while. If you really want to do C++ professionally, that and maybe other FAANG companies seem like they'd give you much higher quality of life.
But the truth is, if you're a C++ developer, you may as well just take up another programming language and get paid more. The data doesn't lie:
C++ was basically the first programming language I really learned, but I seldom use it in the industry, because I don't know why I would intentionally pick a pay cut to do harder work. (I consider C++ to be "harder" than many of the languages above it in pay grade even when doing the same work, for most tasks.)
Salary at an HFT doesnt tell an accurate story. I'd be shocked to learn any quality c++ dev at an HFT pulled down less than 500k last year, and I'd expect most to be well above that.
Hiring C++ isnt especially hard because our pay is opaque. Recruiters will tell you immediately what total comp you can expect and they'll let you know what you can contractually guarantee year 1.
Hiring for C++ is hard because C++ is hard and most people are quite bad at writing even somewhat reasonable code.
I was told $300K about a decade ago and I told them no. I was already making more than that at a big tech company with a much easier pace of work. $500K would have peaked my interest, why didn’t they tell me $500K if that was an option?
A quick google search is suggesting that $200K for the top end of experience, when I was told $300K they said it was as high as they go. Where is the rest of this compensation coming from? Maybe they could give stats for bonuses but when enquired it seemed that the bonus pool was being eaten up elsewhere and the C++ devs were in the back of the line for that.
200k for the salary part might be the highest salary they offer.
Often bonuses can be >100% of the salary. Bonuses vary based on firm performance. The advice is typically "Live within your salary, don't let your lifestyle creep up to demand your full total compensation". HR typically emphasizes that the bonus is not guaranteed (unless you negotiate a guaranteed bonus for some number of years [1-2] after hiring).
Also, salaries/TC have gone up in the last 10 years.
To get the aforementioned $500K it would need to be an average of 150% bonus. And that’s just to equal the FANG equivalent plus some extra for the added intensity. The firm should be able to give historical averages. And I was given the distinct impression that the developers were last in line for the bonus pool, which may have changed in the intervening 10 years, but they should advertise that.
This. I think these firms would have an easier time hiring engineers away from FAANGs, if they realised that FAANG engineers don't precisely understand how the bonus system works. (I think the vagueness is actually seen as a feature of the bonus system!)
They were quite explicit that management, traders and quants take the initial passes at the bonus pool and not to expect much out of it. 100% seemed to be the max not the minimum. They made it clear that C++ devs are support staff and hence second class citizens. And as a second class citizen in a support role it would be hard to make the case for a personal performance bonus.
I think any experienced c++ dev knows there is good money in HFT. Hiring for HFT is also hard, I imagine, because the industry is parasitical. Id like to look at my work and feel that it is contributing something net positive to society.
Same with the poker machines. Recruiters gotta recruit, but I’d just make my own meth if all I cared about was the money.
HFT can cover a wide range of diff types of firms/latencies. Bonus structure also makes it so the salary might not be as high, and bonuses can be contingent on performance. This might be true at some of the larger firms on successful desks, but I don't think it is true across the board.
Google has basically thrown the towel in the ring when it comes to C++ considering they're building a replacement like Carbon and also using rust in and more places so they're likely pivoting to those two instead
I mean no, if you're happy at Google doing C++ then by all means you can probably keep doing it for a while. I don't think pivoting is particularly hard for experienced devs, so it's probably fine to hold it off, though I could be wrong.
I don't think I know of many buy side firms that pay any less than Google, Microsoft or Meta. Salary just tends to be relatively small compared to the bonus or return on invested capital in the fund.
That's probably why finance is having problems. I know plenty of great C++ devs out here in flyover country. A lot of shops that hire them go bust, or outsource, and they move on to something else because finance is clueless about how to scoop them up (pay a lot, do remote, or establish a branch office).
just a side note: long before a small part of the programming world took over this acronym, it used to mean the sound engineer (and sometimes other staff) that were in the venue, embedded in the crowd, working on live sound while the talent was up on stage. "back of house" was behind the stage, "front of house" was the room/venue itself, and the people working in it.
I’m not sure the programming world took over the acronym, I think OP just confused them. In finance at least, the terms Front Office and Back Office are used. I’ve never heard anyone use the restaurant/entertainment variants used.
I'd say HFT/prop trading/market making/hedge funds, since those are the only places that are hiring right now and pay good money.
The usual destinations for smart and motivated new grads are (not counting very early startups/making your own company):
1. Top tier HFT/prop firm (Jane Street, HRT, Jump, etc.)
2. Meta, larger unicorns like Stripe, Databricks, etc.
3. Google
4. Amazon, Microsoft, etc.
Obviously im leaving out a lot of places but this is generally what I've seen.
Id say for most people FAANG is still the top option, and for people that want to shoot beyond FAANG, trading firms are probably the next target.
If you were including very early startups in this list, I've noticed that the smartest people often join promising startups as an early engineer, or make their own company. I'd put them above trading firms, but the risk is way higher.
HFT, prop trading, market makers and the like are also finance firms right? They are still pretty coveted by those who are aware of their existence. Jump Trading, Citadel, Jane Street, DE Shaw etc are considered highly prestigious and competitive.
There are certainly financial firms that people are less interested in though, namely banks.
Lol, couldn't be further from the truth. Ive gotten multiple offers at FAANG and Trading firms (thinkCitadel Jump, Optiver, HRT, IMC, etc.). Trading comp blew my FAANG offers out of the water. And if you went to MIT, CMU, or Berkeley right now I would guarantee you the top students are gunning for an internship at one of those firms.
Perhaps "prestige" may be lower from an external perspective (Your parents will brag about you being at Google, but probably not Jane Street), and Id also agree with the fact that the top 0.01% probably either make their own startup or join as a founding engineer at a startup, but the top 0.1% of students are definitely going for Prop trading/hedge fund jobs.
This speaks to the point in the article "The real problem is that C++ is neither easy nor loved," which they offset with "The language may be hard. But it's also worth it."
The problem is that there's a law of diminishing returns to compensation. If you can work with a tool you like that helps you meet milestones and general expectations for $X00k generally leading to pleasant days, or can work with a tool that makes your life harder and leads to higher stress fewer pleasant days for $2X00k... sure there's going to be people who take the extra money. But there's also going to be people who say to themselves "yeah, it turns out I'm plenty well compensated at $X00k I'll take the extra quality of life."
"Worth it" is a value judgment. How many people managing the financial firms decided it was worth it to invest in C++?
To further the idea, C++ can be loved if the firms invest dollars, invest marketing (open source, other ways) of it. They should support/invest in the community they want to hire from.
They're focused on the language. The language isn't the problem. Of the people I've met in finance, there are some really strong and offputting trends: they're uniformly dismissive of work/life balance, they're almost uniformly the worst stereotype of tech-bro, and aside from the rampant cocaine use, they're hugely socially conservative, and every single one values profit over ethics.
It's not the language, it's the extremely toxic culture. Any programmer worth their salt can march into a nasty codebase of whatever language, and make it dance. But financial folk don't want to employ humans with all their complexity, they want robots who will run themselves into the ground for cash. So they get young men who burn out quickly and retire ASAP. The problem isn't the language. The problem isn't the pay. The problem is the extractive culture. Finance folks focus on short term profits to the detriment of their future. And now they're wondering "where can we find programmers" after they've been burning them like so many trees. Go figure.
> Any programmer worth their salt can march into a nasty codebase of whatever language,
Correct, I wonder why people both technical and non-technical focus on this aspect a lot. ( my guess is that they are incompetent themselves).
Agreed, if you want someone for two or three months you probably want someone who knows the language and it's ecosystem pretty well. Any work that is more than six months should be nearly language independent.
It really makes me wonder. I see so many job ads where specific-language mastery is a top-line requirement. And I know people who know that this is not justified, but keep doing it...
> Any work that is more than six months should be nearly language independent.
I'm not sure this is true in finance. Speed matters. A lot. It's called high frequency trading for a reason. These firms will spend a million bucks just to make their fiber optic cables 1 foot shorter.
Just the kind of short-sighted idiocy that keeps good people out of the industry. How long does it take to get that network upgrade installed? It doesn't happen overnight. It takes me a week to get decent at a new language, a month to get good. That's, what, $10-20k on "training" assuming an output of zero in that first month? That's peanuts.
I wonder (with no supporting data) if they are griping because in C++ they've created horrid technical debt that they have a hard time hiring people to maintain.
The key to being a developer in finance is to work in a software shop.
Working at a bank / prop firm is going to be extremely stressful. Working at the shop that all the big banks buy their trading software from is like 80-90% of the pay but none of the stress.
I love it. I get to do real, hard engineering for big pay without working on ad tech or javascript.
I wish. I've never received an offer that high for C or C++ job. Then again I haven't applied at any trading firms, and I wouldn't be considered Senior.
C++ quant jobs were already some of the highest-paying jobs in the technology market. A step above FAANG in many cases.
There's more to the story than just comp. Even increasing comp wouldn't immediately generate new developers, as it takes a very long time for the increased comp to incentivize new students and junior engineers to move in that direction in their career.
High performance C++ takes a lot of time and effort to learn, and even longer to master. Maybe the real issue is that there has been a surplus of high-paying jobs that are much easier and require a lot less effort to master.
"Already" doesn't mean it couldn't be raised further. Have you seen C-suite salaries?
Also you don't have to only incentivize grads. Getting experienced devs to jump ship is the primary goal. Which a $100k+ raise would certainly incentivize.
The company they based the story on appears to be a cryptocurrency firm, too. That'll exclude a lot of otherwise qualified candidates due to ethical or business model concerns — especially since C++ developers tend to be older, they're more likely to understand the risks of jumping into a bubble and have higher expectations for things like work/life balance.
You can't pay me enough to go back to writing c++ code.
I despise the language, 80% of my time is spent figuring out how to beat it into submission to get it to do what I want, which leaves very little brain power left over for designing well architected software.
Modern languages get easy access to a large number of powerful design tools, C++ I have the same tools but it's stuck behind an interface (headers, the build system) originally made in the 70s.
But also, these companies have a lot of weird modern C++ shibboleths in their interview processes. If they compromised on those and went for low-level engineering, performance engineering, and software engineering skill instead, there would be many more candidates.
This, among other reasons, is why I avoided applying to these places when my C++ skills were much more current. Certain shibboleths might have been applicable, but these were things any junior developer could have learned and made use of with a few minutes' study: they shouldn't be used in an interview process.
When fresh out of college, I used to pride myself knowing C++. I used to revel in its complexity because it made me feel a cut above the rest. How naive & stupid I was.
I have not worked in C++ for a long time, I cannot climb the mountain of complexity again.
lots of expensive California C++ coding got outsourced to the Ukraine and other places, faster than you can say 'dollar conversion' a long time ago. What is this trend, similar to "shortage of truck drivers" and "this airline stewardess job pays up to $300k per year" ?!
Heh. I'm pretty proficient in modern C++, and it is my favorite tool for a lot of things, but my PHP job pays way more than any C++ position available. Did an interview once for Senior C++ Engineer, embedded software in the medical device space. All went good, until the offer: $100k.
Articles like this are nothing more than a desperate attempt at getting younger generations to learn said topic, so companies can pay them crappy salaries.
Embedded roles pay less than almost any other role... I feel there should be some sort of diagram possible that explains which industries and technologies pay more or less.
Hardware is just slow and ugly. It’s not scalable and really profitable. Write C and C++ code all day for embedded devices and decided, that slowly I want to do something different and more profitable.
Not just embedded, robotics or automotive have pretty low C++ salaries while much higher for Java or even JavaScript... C++ devs are punished for being more capable.
Not posting to make a counterpoint but simply because related and interesting for the C++ folks around here.
> Wt is a web GUI library in modern C++. Quickly develop highly interactive web UIs with widgets, without having to write a single line of JavaScript. Wt handles all request handling and page rendering for you, so you can focus on functionality.
Thanks, but just a reminder of why we don't use C++ for web applications: creating a web app is basically a string manipulation problem. The work in most cases is just getting data from a database and returning text that represents the HTML+CSS in the web page. Not only you don't need the C++ speed to do this process, but string manipulation is also the weak spot of C++, due to the need for manual memory management.
Automotive is just embedded with some even more painful tool chains, to be fair.
I get paid very well doing embedded firmware dev, but that’s because we don’t make money on our hardware, we make money on the software that it talks to for industrial IoT analytics
Not really if you know where to look and work on platforms. Pay is at par with backend devs if not full stack ones.
ML/AI is the where the money is though.
> I feel there should be some sort of diagram possible that explains which industries and technologies pay more or less.
Is the entity you are selling your services to earning a large profit margin? If yes, then it is possible (but not guaranteed) for you to earn more. If not, then look elsewhere.
Generally, this situation happens in businesses that can scale with little to no marginal costs (software, media), can use governments to defend its property (intellectual property, land), and can be easily used as collateral (land) with which you can obtain leverage (money).
1. A lot of the tooling is made by the hardware suppliers. Hardware suppliers tend to be very bad at writing desktop software; I have some theories as to why that is, but no direct evidence for them.
2. When tools are selected, they are rarely evaluated by software developers who will be using them. It's more like "Here's a list of boxes anything our development tools need to check" and then the final selection for anything that checks engoubh boxes is done for business reasons (cost, likely availability of support down the line &c.)
3. The same reason that embedded developers are often paid poor salaries; for a lot of hardware companies, the firmware development is treated more as a cost-center than as something that generates revenue.
I had a large group of devs I used to hang out with. It was about 50/50 front-end and C, C++ guys. Over the last decade or so, every single C developer either transitioned to PHP like yourself, or went the full-stack JS route and have never looked back.
And it was all over the issues around dealing with legacy systems and the poor pay. One guy told me flat out he can make close to twice as much being a very in demand JS developer with great benefits and reasonable hours compared to the horror show of working in government (military) or finance.
Think about how web companies can have very low up-front costs, use a cloud provider and some high-level frameworks for python or JS etc, make a stupid social-media connected app, and start making big money (or get investments assuming they will after capturing many users).
Then think about hardware companies - it's a very competitive space, it's mostly a commodity, the high-level software doesn't care so much about the specific chips providing those cores of cpu and gigs of ram, and what's available on the market is really amazingly powerful at a really amazingly reasonable price, due to competition with other providers in the market, and with older hardware!
It does seem kinda perverse, but ... the closer you are working to the hardware, the cheaper the market for your work, but the further up the stack, the more potential for high pay, based on the higher monetary efficiency of those companies, by running very in-efficiently on super-competitive hardware, and differentiating with features and services etc.
I used to work for an industrial company in the defense sector. We were working on very complex problems with difficult requirements in term of resilience and performance. It was extremely interesting: complex algorithms, redondant architecture, hard real time development, most of it in C++ or Ada. Deadlines were tight. It was quite stressful and the pay was miserable.
I left the field entirely but most of my former colleagues now work as fullstack developers for companies building SaaS solutions. They all complain about how boring it is but they all have doubled their total comp.
Meanwhile, I heard from my former boss that the company still complain that the part of the org doing software is more expensive on average per employee that the ones doing production (apparently no one has realised we don’t hire blue collar workers in this part of the company) and keeps grumbling about how talent is too hard to retain in my city.
Knowing people who work in the defense/military sector, this is what I gather as well. Pay is lower, sometimes much lower, compared to other jobs. I know some people stay in it out of ideology, or because they're natural lifers, drifted there, it was ok, and they stayed, not bothered by the low pay very much (no hard feelings, I'm a natural born lifer too!). It can be stressful but I gather that those companies slowly start to realize they're losing their old workforce and try to attract younger crowds by making the work environment "modern, young and dynamic" like startups (except for the actual pay, of course). I don't know if it works. Probably not.
Hmm, what is the highest paying JS job you have seen/heard of? I am not particularly good and by far the highest quote I've ever gotten was ~100k euro after taxes. Not bad at all but required relocation.
I've a frontend-only friend at $big_tech_co who's on $200k TC post-tax with a half decade of experience. Lives in a major metro area in the US, not sure what their rates are abroad.
In general, the big cos hire maybe 1 JS dev for every 2 or 3 backend devs. But they're on the same payscale. From what I've heard, it's more challenging to climb the level ladder, but if you come in at a terminal level and aren't particularly interested in that stuff, it's pretty comfortable.
Midwestern state, large health care company - between $150-$200K (this is FTE status with benefits)
You can also be a contractor (hourly, no benefits) and squeeze a bit more out and just jump around from company to company. Senior JS devs are in seriously high demand right now. I get around 5-6 emails a day from recruiters looking for Senior JS devs.
Pretty funny. For a hardware/robotics company, software is a cost center. For software company, hardware is a cost center. In-group are profit and out-group are cost.
If I am a C++ developer, in my late 50s, close to retirement, and know C++ fairly well, don't want to learn a brand new system which I won't be coding in for much longer, and already have my financials all set...
I won't be looking for that early retirement big cash payouts. I just want my flow of cash for a good retirement, to go on my vacations, and to buy gifts for the kids / grandkids.
I'd be willing to settle for a lower pay with low stress and solid job security.
Remember the desires of people later in life and those early in life aren't the same. If you got 10 more years of work left, you don't want to be in a high stakes high intensity work environment. I worked with one such man. He'd fall asleep while coding mid day. Nobody bothered him. He just chipped away at his projects at his own pace and was happy to not be bothered.
Sounds like such a company is looking for a boomer/genx who's still got skills and willing to settle for not being bothered too much.
Related to age factors: so long as the "primary" development language for videogames remains C++ there's always going to be a multi-generational talent pool for C++. Young naive programmers get into videogames until they burn out or are laid off due to ageism then there's "always" "fresh" new C++ talent for other industries too immediately following those videogame roles (assuming the burnout isn't total, such as strokes).
COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
> Related to age factors: so long as the "primary" development language for videogames remains C++ there's always going to be a multi-generational talent pool for C++. Young naive programmers get into videogames until they burn out or are laid off due to ageism then there's "always" "fresh" new C++ talent for other industries too immediately following those videogame roles (assuming the burnout isn't total, such as strokes).
> COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Not anymore.
I am frequenting gamedev forums, and reading gamedev chatter in general (seeing youtube videos on game conferences, presentations on games development, etc).
Maybe 1 in 10 of the people in these gamedev places actually program in C++. Mostly they'll use Unity (C#) or Unreal Engine Blueprints, with some Godot getting popular and a few statistical-noise engines being used (Love2d, etc).
What you are saying used to be true; on gamedev forums almost everyone used to be able to program in C++. Now very few do.
My question is what engines are the AAA companies hiring people to work with?
Yes, Unity is the default engine in the indie scene, but what are EA, Ubisoft, Embracer, Take Two, etc. hiring people to work with? Because these are the meat grinders who hire fresh college grads by the hundreds and work them like oxen until they burn out.
Good point. I've been looking almost exclusively at small teams.
I wonder how many programmers are used at the AAA publishers. Maybe someone on HN who works as a gamedev (ISTR one or two people in the past saying that they worked for AAA developers) can answer that one.
Yes, C# is definitely getting a leg up these days (nearly a decade later than Microsoft's and Mono/Xamarin's separate big attempts to make it happen), but it is still seen as more of a "scripting language" than source or engine language. Unity itself is still built in C/C++. Godot is written in C/C++ and its default scripting language is the odd GDScript with some unique C/C++-isms and it takes extra effort to use C# with Godot (though a lot of post-Unity devs seem to be growing happy with C# in Godot these days). Unity is semi-closed/proprietary source so doesn't get a lot of indie dev contributions, but Godot is open source and I have heard of indie devs needing to contribute C/C++ upstream.
(As an aside: I've got my eyes on FNA which just hit some milestones with using .NET 7 AOT for pure C# games on the major consoles. That's pretty exciting.)
Unreal is the truly wild one because to my understanding Unreal Engine Blueprints are a terrible half-baked not-quite-scripting language and most Unreal developers have to do most of their "proper" scripting in C/C++ directly. (With some statistical anomalies allegedly doing things like bolting in Lua interpreters.)
But yeah, outside of indies and small game companies my impression is that C/C++ is still king and there's some consternation that developers learning from the indie side are sometimes, if interviewing for AAA teams, getting shuttled to "tools" positions because that's where AAA's only C# code lives (in non-critical tools outside of the games). (Though that's mostly anecdata from reading similar gamedev forums.)
It's a demand side issue. Most C++ jobs are maintenance jobs. Most maintenance jobs are at low-growth companies who can't justify the TC of engineers at high-growth companies to their board.
There are pockets of the C++ ecosystem where this isn't true (e.g. HFT).
But bottom-line, it's a business thing, not a skills thing. There are also a lot more C++ devs than the zeitgeist would suggest. Far too many to cause a "COBOL effect" where supply constraints on talent dictate market price.
C++ isn't necessary in many business contexts, and can result a worse business overall outcome than alternatives. If it's a harder tool for people to use, and the use of the hard tool isn't necessary, why would you use it? Why not use an easy tool? Especially if the easy tool means more people can wield it, so there's a wider labor pool to draw from, or a reduced error rate from tool-difficulty-induced defects.
Indeed, many businesses correctly decide there's no benefit to using a difficult tool that isn't required, and choose an easier tool that produces a better business outcome.
e.g. suppose you're a non-tech enterprise (bank, utility, etc) and you need to build a bunch of backend web services to support your internal operations. If you decide to implement them in Go, which is arguably a domain specific language for building web services, then you can probably deliver the project by hiring a bunch of fresh grads and putting one intermediate to senior programmer in place to lead the effort, even if no one has any Go experience.
arguably if you try to deliver the same business outcome in a random enterprise context using C++, a project team will likely have a far more difficult time getting basic HTTP / TLS server stuff in place, and if there's lots of rookies on the team, they'll keep making foot-gun memory error mistakes.
Sure, maybe if it was built in C++ by highly senior engineers, and subjected to a thorough QA process, you could end up with a system that's much more efficient at runtime than what could be cobbled together by less experienced engineers with an easier language and a good standard library. But in most business settings efficiency isn't the bottleneck, it's delivery speed and then maintenance costs, which are driven by staffing and how expensive it is to change the code each time the requirements change.
Not really. I've spent more time debugging JavaScript than debugging C++.
It used to be hard. Modern C++ is actually a quite pleasant language.
The issue is libraries. For example, one very basic functionality of any programming language is DB connection.
In particular, MySQL is very widely used. The C++ libraries (c++ connector) are older, less maintained and just plain broken in the last Ubuntu (it's Oracle's fault, and that can't be helped). They are more stable in Python, for example. The reason is trying to force SSL, reading the source code of the C++ connector it's clear it was intentional.
So, for many things that should have a well maintained library, there's actually not a good C++ one. Web servers are another example. There are only one or two libraries, very opinionated and with "proprietary" widgets, and that's it. Nothing comparable to Laravel or FastAPI.
In other words: the language is fine. C++ is a fine language with a fast runtime, and modern practices and implementations are pleasant to use. It's the disregarded ecosystem in C++ the one that needs improvements. Libraries, package management, build systems, etc. Even then, for performance, some things are only available in C++.
Labor supply stories never talk about salaries. I can also see lots of references to embedded and close-to-hardware jobs, which means low salaries, unsexy code, and flawed/buggy toolchains compared to mainstream platforms.
It's right there in the article: "demand". Why do business people pretend basic supply and demand first day microeconomics 101 doesn't exist as soon as you say "labor"?
I suppose this is more fuel for Rust adoption. Rustaceans, is the war won?
Btw, it is INSANE that we pay engineering positions (you know, real ones like electrical/hardware/materials) so poorly compared to software devs. Engineering has professional organizations which, like the AMA, should be able to enforce some degree of good pay.
It’s the growth, not the profit. Software engineering is a lever for growth for businesses designed that way. If you can grow revenue by $100M by spending $10M on engineer salaries, it usually makes sense.
On the other hand companies with steady profits and little growth have no such expectations and try to pay as little as possible for the software engineers they do need.
Big companies don't post profits for tax avoidance reasons. They use various strategies to minimise profits - or ideally operating at a loss, so that they don't pay tax or very little. They also use this as an argument "look we don't make any money so we can't pay you any more", while at the same time you hear CEO buying themselves another supercar or a beach house.
If you were to look into trading companies, mostly located in Chicago/NY, you would find positions paying competitively (or better) with FAANG salaries.
Yep, I'm in the same boat. C++ jobs always pay like shit, so I sling web apis together with C# and make 3x as much. It's way easier and less stressful. I'll only use C++ for hobby projects now, and then only if it's the right tool for that job.
Welcome to the club, here is another issue with C++ jobs, they are hardly open to the idea of remote work, unless writing C++ is a detail, e.g. main application is C# and there are some native libs there.
It's not the C++, it's the embedded. Embedded is paid miserably, everywhere, no matter how complex or interesting. Simply put, having to manufacture things, with its supply chain, warehousing, manufacturing, ... is never gonna have the margins of a purely software or financial product. Since the employees' salaries depend on the profit from that physical thing, it can never compete w/ software / finance.
The only well paid embedded jobs involve producing weapons ('defence') or gambling ('gaming'), and I'd rather sell crack to kindergartners while also prostituting myself than do that. I did get a bunch of those offers and still do get them every now and again, even though I'm happily employed.
Moved to finance, never looked back. People should plain refuse to work in embedded, maybe then thing will get better.
Also, C++ is the differentiator. People hire for other languages (C# and Rust, in my experience) based on your deep C++ knowledge. And this does make sense, this is a great proxy for your development skills and potential.
Do you think the many embedded engineers working at Apple, TI, AMD, Intel, etc are paid significantly worse than their higher level software counterparts?
I do, in fact. The reason is that most embedded people are recruited from the ranks of EEs. At least around here (Europe), 1.5-2x more EEs graduate each year compared to CS people, and EEs doing EE stuff are paid even worse than embedded, it's a step up for them. They don't and likely can't ask for more. Surely, some EEs learn CS stuff on their own and start working dev jobs, but they're the exception.
I've worked with a lot of EEs, and their general programming knowledge (especially knowledge of best practices, tooling, software architecture) is way worse than CS people, in general, across companies and countries. Every time, the best devs were CS, even when it was 100% embedded or even FPGAs (which are not taught to any CS students, yet are taught to every EE student). I personally know maybe a couple of EEs that are great devs (through their own effort and interest), compared to at least a dozen of CS people. However, CS people generally know almost nothing about analog design and at hundreds of MHz (table stakes for serious stuff since 2010) things start getting pretty analog whether you like it or not, so you have to hire EEs anyway.
I interviewed for Amazon for an embedded/mixed role because that was my forte at the time, and the compensation offered was nothing special, worse than even a mediocre finance sector offer, much better than automotive or general embedded (medical, industry / robots). Could never get an Apple interview (they passed on me twice), though, and I never even thought about the rest (that would require relocation to to places I don't care about).
But since I never actually worked for those companies or have any concrete data I could be completely mistaken. I only have friends working in FANGs in non-embedded roles and embedded friends only working for shit-paying companies, plus some of them are not willing to discuss salaries (suckers). Also, I get the feeling that AMD / Intel / Nvidia operate a bit different than the rest.
One of my high school teachers, who I respect a lot, argued that what a CS grad can do, an EE grad could as weel, and more. Therefore he recommended the EE career.
I wanted to get away from physics so I ignored that, and in hindsight it was 100% the right choice. But the advice was well intentioned and I considered it.
For reasons I can only speculate on, EE programs enlist way more people.
It may be because EE is older and more entrenched, or because of ties with the industry. Engineering of any kind has centuries of prestige, historic industrial support, historic large buildings and grants, etc. I would bet on the comparative ease of hiring staff for EE, though. It does make some kind of sense for some academy-prone people to go the academia route in EE. Especially if you sprinkle in some industry side-jobs, because the industry side is not that cushy by itself. This likely makes it easier to staff EE faculties. For CS, academia only makes sense if you have direct industry support (like doing machine learning w/ direct support from a FAANG), and you can expect something like that in very few places in Europe (Zurich, London, maybe Amsterdam?). Otherwise, you really have to hate making money and being respected to get into CS academia. There's a distinct lack of staff for CS, and they let anyone be assistants (at least they did half a decade ago). I remember there being some competition for math positions, and a free for all in CS. Some smart CS people do get fooled into joining, and last around a year until they see it's a waste of time. No amount of academic benefits in later life can offset the accumulated difference in pay.
As an actual failed EE student (moved to CS after 1 year of EE an eternity ago), I definitely agree that it's way harder. I even think that it's not just my affinities, but it objectively requires more effort and is more dense with difficult stuff. What's ironic is that the (officialy!) best EE student of that generation is now a Rust dev for some crypto company (last time I saw him on LinkedIn).
Same in video games. Many C++ engineers are learning JS in spare time to hopefully jump over to something that pays 4-5x.
My personal experience also says that you spend much less time to build something profitable in JS and PHP than in C or C++.
I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up. Hopefully as a result of moving to languages like Rust - it would work out best for all developers. But it's not looking good in the C++ land salary-wise now.
> I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up.
Maybe. I've made the jump from pure embedded (spent over 15 years in embedded) to backend (Go, with some rudimentary Java thrown into the mix). I literally doubled my salary in the space of 12 months.
In 20 years, are they going to hire my retired old ass to make their codebase live another 5 years longer, or will they simply bite the bullet and rewrite?
> Hopefully as a result of moving to languages like Rust - it would work out best for all developers.
It could happen, but I'm not that bullish on that happening:
1. No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety[1] - the end result of using Rust on a 2kb RAM/8MHz chip (atmega328, or xmega, or one of the stm32s, for example) is going to be using unsafe everywhere anyway.
2. High rampup - the majority of knowledge needed for low-level comes from EE, not CS. Already Rust has problems with adoption amongst CS people, who (in theory anyway) have all the requisite knowledge and motivation to climb the learning curve. I'd bet money that EEs won't even bother looking beyond the awful syntax.
3. Better alternatives - all those higher-level embedded projects such as RPi, Beaglebone, etc that run Linux have better alternatives for programming them than Rust. Most custom code written for the RPi is in Python, for example. Someone looking to develop on these boards is almost certainly better off using Go instead of Python, and Python instead of Rust.
So given that there's a) no benefit on low-powered devices, b) there's better alternatives on high-powered devices and c) it's a complicated language with slow ramp-up, I'm having trouble in seeing exactly where it fits in for embedded.
> But it's not looking good in the C++ land salary-wise now.
Nope, it isn't. If enough C++ devs jump ship (and, to be honest, in low-level embedded C++ as you know it isn't used much anyway), then salaries will rise again.
The problem is, as someone else pointed out, that many of the places using C++ are shooting themselves in the foot, because they want senior and experienced people who can ramp up quickly on the latest C++ standard, but without a pipeline of unskilled/juniors, there's only a few number of years before there'd be out of any C++ devs.
And because it's not an attractive language, there's no one switching from (for example) Java to C++, or C# to C++, while there are plenty switching from C++ to Java or C#.
[1] Beyond which, it is not clear if safe Rust will ever be able to interact with various embedded OSes for these chips; most of them are external kernels anyway, so there is no way to use those kernels without using C.
The only place I can see Rust (or Nim, in our case, mainly so we can easily wire in existing C libraries and vendor provided drivers) in embedded land are the “in betweeners” or “crossover” chips — ESP32-S3, some of the i.MX SOCs, that sort of thing.
Where they have enough grunt to do a lot of tasks at the same time, all driven by config over the network, with less hard real-time requirements for some tasks and stronger requirements for others.
That’s not that big a segment though, I would think. And in some ways, just chucking extra slower chips at the problem on the same board is simpler.
> No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety
The Rust embedded ecosystem has lots of benefits in addition to pure memory safety, which is basically table stakes for a modern language. It gives you a vastly improved DevX, at least if you aren't using hardware that's too exotic for which only proprietary C/C++ toolchains are available.
C++ is the only language I know where you can think you’ve learned it, then stumble upon a completely alien codebase. The decades-long history of the language has spawned all kinds of dialects and template-powered Lovecraftian horrors.
My dream is to have an AI that automatically unwraps and de-clever's a codebase to something super simple. Completely unrealistic, but even a semi-manual tool I can use on complex chunks would be amazing.
Scala is worse, people tend to invent their own DSLs in it and you end up with two libraries unable to work with each other without wrappers, like in the old days of C++...
As someone who is a fan of Common Lisp, this state of the world kind of grinds my gears. "Lisp isn't suitable for large teams because it's too customizable" while it takes me an order of magnitude more time and effort to come up to speed on a new C++ code-base (day job) compared to doing the same on a new CL code-base (hobby).
Some of it is tooling: It's trivial to walk through expansions of Lisp macros, while the tooling for C++ is ... less ergonomic to say the least.
Some of it is a weird combination of technical/cultural. You can do a lot more in Lisp without reaching for macros as compared to C++ and templates. In addition, every CL style guide ever says "don't use a macro when a function will do." There's also the culture of "Read *Let over Lambda" (a book on Lisp macrology), now don't ever do any of that unless you absolutely have to"
I don't know if finance people would consider me "talented", but as a developer who has been using C++ for over a decade, not once in all that time have I ever wanted to work in HFT.
I don't know if that's a solvable problem (maybe higher pay? But I hear they pay well already). Or maybe my perspective is an uncommon one. I just think it's silly to say there's a shortage of C++ devs because a specific industry has hiring difficulties. The article says that it's not a HFT-specific problem, but doesn't go into it.
Why stop there, any one who spends money on internement is unproductive human being, it is immoral to pay for Netflix instead of helping kid in Africa, right ?
The entertainment industry is useful to keep people entertained, which is good for their overall well-being. I think you don't have to feel bad about your Netflix subscription. And the sustainable development goals are not only about helping kids in Africa.
If I was picking language for a new project, I would take c++ over golang or Java hands down. Many people don't realize it, but modern c++ is actually very good.
Java's gotten a lot better with latency with new GCs. Some codebases use statically-allocated memory in Java and do it very carefully. Sometimes shops will just shut off the GC. Graal also gives you AOT options now.
One thing I read is that memory allocation can be faster in Java because malloc can result in system calls. Deallocation is what's slower.
I found 10 years back that getting into C++ jobs that would give you valuable experience were the ones that already required you to have that experience, or have very good connections. The ones that were easier to get into were the C-with-classes balls of mud that only were written in the first place because they were early for Enterprise Java to be invented, I doubted that entering from the latter would give you a pathway to the former.
I decided it wasn't worth pursuing, went from doing Clojure to Big Data in Scala.
Ten years later, I hear that there's not enough "C++ developers", read, "C++ developers with the desired qualifications". Seems straightforward to figure out why.
> Writing new C++ code with all the modern approaches and tooling doesn't sound so bad.
Uh, but it still kinda sucks, if only because the nice way that looks idiomatic is usually the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety (operator[]).
The correct way is usual the ugly way, because it seems like the committee puts C++ arcanum knowledge above all else, instead of developer satisfaction or maintainability
C++ puts you don't pay for [at runtime!] what you don't use above all use. However that often means you have to know the arcanum bits to decide if need to pay for something. You can save a bit of CPU time if you don't check if a pointer is null - which is a great thing to do if you have knowledge that the pointer cannot be null - and also something that is very easy to screw up so most languages don't give you the option. (which is the right thing for them to do - a lot of people are writing C++ where they could write something else)
> the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety
I don't know where you got that idea from, but with an up-to-date compiler variants are safer and more performant than the traditional approach (classes hierarchies), and std::optional is safer and 99.9% as performant as a nullable pointer.
> and std::optional is safer and 99.9% as performant as a nullable pointer.
Except for it taking up twice the memory as a pointer (https://godbolt.org/z/5We9zEbvh) and it not doing anything in regards to safety when using pointers. Even if you're replacing a nullable-pointer with a std::optional you're still handling landmines when using operator* or operator-> - the most convenient ways to use std::optional.
The fact that modern C++ still added more easy to hit UB in std::optional blows my mind. "But making it safe would be slow!" and "-> being safe would be inconsistent with the rest of the language".
C++ is doomed forever to have safety-third design.
Same can be said for BASIC, my favourite childhood language.
you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.
Just spent two years writing a medium size fresh c++ codebase in modern style with all the warnings turned to max and nearly every static analysis tool we could throw at it from day 1. It’s been an utter pleasure with no pain that can be blamed on c++ alone. It can be done :)
for stuff like gaming & HFT, you are probably forced to do it in C++, it is a sad reality affecting small % of developers. for everything else, if you are still building fresh new projects in C++, you are making a big mistake.
C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ -
I do precise timing with accuracy up to +/- 1ns and some of my hardware are of 10-100pt resolution.
I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink.
I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
Simply put cpp gives you ultimate control. If you want to be absolutely economical with the CPU/memory, you need to do things likely preallocate memory and making sure you don't get cache misses and branch mispredicts.
For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
I think it gets close. Certainly close enough that if you're a small team doing similar things, use Rust. If you have time to fiddle with the little things, go with cpp.
We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
cross-platform is no longer a bonus of a language or a toolchain. it is a must to have feature in any modern language.
to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables.
there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
> You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
you also need to worry about which stdlib to use in C++ - too bad!
> SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
please stop such nonsense. AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
> the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process
why this is even related to the ongoing C++ discussion? once you have the package, you need to somehow distribute it, app store, http service, bittorrent you name it. but why it is even relate to any programming language since you brought it up here?
you can probably argue that golang's stw isn't going to help when building audio stuff, but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way by rust. audio plugin or not, I don't care, in the end it is just the same machine code.
> AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
Well that's nice. What about ARM SIMD? And the M2 variant? You're suggesting that every SIMD instruction set should be accessible via the same language-invariant syntax or else a language is just broken?
> but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way
the point is that it is NOT done by a legacy language known as C++, and it should not be done by the young languages that go by any other name, contrary to your claim that essentially everything should be a part of the language/compiler/toolchain itself.
I personally consider C or C++ written with the best-of-breed static analysis deployed on it, preferably from day one, to essentially be a different language. Most of the criticisms of C or C++ are eliminated under this setup. You get different ones; the resulting language is even more complex than the base languages, and requires an even deeper understanding of what's going on, but at least you have the requisite support to learn it, so in the end it's probably a net positive even in terms of the ability to learn it.
This is, obviously, a very opinionated opinion.
If I was going to be forced to do it, this is how I'd want to do it.
I think that's great if you're writing from scratch, but I think it misses the point that the previous poster was making.
Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C.
I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
Yeah I did a few years in finance on a c++98 code base for my sins. (My colleagues were great, but the code was not optimal to say the least. Then again I really loved making it better and faster.) My intention above was just to say experiences with c++ vary with circumstances and if you are lucky legacy isn’t part of your day to day :)
Most of the stereotypical pain of C++ lives in legacy codebases where they're passing raw pointers all over the place, doing horrible things with array indexes, and poorly re-implementing the standard library containers. If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
> If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful".
If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap.
And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
Have a gut feeling that polyglots can’t handle C++ so well because their strategies for using several languages fail: one has to know C++ well in order to be able to use it successfully.
I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero.
Polyglots truly are jacks of all trades and masters of none.
I only have a small codebase, but I mirror the sentiment.
If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain.
C++ gets underserved hate by people who don't care about doing a good job anyway.
"Legacy" is meaningless in the contect you've used it.
C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.
Speaking as a professional C++ developer for the past 20 years, I think this sums it up well.
A modern project should be able to use most of C++17 at least. Even if you still need to target some ancient garbage like Windows XP, you can use an MSVC toolchain that supports C++17. That's a good basis to work from.
So your real concern is the moldy old code that's written for C++03, that's still not using std::unique_ptr or anything equivalent. If you're given license to finally rewrite that code to modern standards, that can be fun if it's not a complete mess. But if you just have to live with it, and still write C++03, absolutely not, I would never do that job.
do you have a good template (pun intended) on how to best learn modern c++? coming from Go and Typescript which have very mature devX tooling, c++ is a landmine to navigate. and that's when I already have professional experience with it (the place just didn't have strong c++ culture)
Try watching the "back to basics" videos from the last 4 years' cppcons.
But that's mostly learning modern paradigms of the language.
If you also mean the tooling, then it depends: Learn CMake which is sort of an industry standard. There are books and videos, but for a concrete experience, try looking through the CMakeLists.txt of some non-trivial C++ open source project.
I have license to any one C++03 area to C++14 (and I have my own implementation of optional that I'm allowed to use when until C++17 is available). However I can only do a few of them so I need to target where. If C++03 code has been working great for years and isn't broke, why would I break it?
> If you're given license to finally rewrite that [C++03] code to modern standards
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?
> It's not like C++20 is completely different. There's just a lot more utilities in the stdlib so hopefully less raw pointer magic.
What was best practice for C++03 is not the same for C++20.
Switching a codebase from C++03 to C++20 for a nontrivial codebase means changing design so radically it may as well be a new project, rewritten from scratch.
It'd certainly be easier to rewrite in C++20 for the C++03 projects I've recently worked on, than to try to squash in a C++20 design.
- Immature compiler susceptible to generating performance traps
- Build times even longer than the infamous ones in C++
- Simplistic declarative-based build system
- Inability to opt-in or to opt-out from static analysis
- Harder to scratch up quick PoCs because borrow-checker
- More complicated compilation model making it harder to understand, debug and implement workarounds when codegen goes south
- Much smaller ecosystem - libraries, toolchains, tools, ...
- False sense of security - by default it relies on the ecosystem whose runtime and its OS is implemented in "unsafe" languages
- Cannot even live to its "safety" promise because hardest problems cannot be solved without unsafe sections
I sincerely wish it was different but at this moment I am not convinced that Rust trade-offs are worth switching to it. This is the PoV coming from a system-level programming, very close to the OS, and with a lot of difficult memory and concurrency scaling issues.
My first real C++ job involved a bug in a largely technical indebted codebase, lines of code in the millions.
I spent two months asking one guy who knew about it for help. I really understood the concept of "hostage taker" in a software team. It's the guy you cannot fire and will constantly arm-wrestle everybody where there is a problem, never really helping, and continuing to write bad code that allows him to keep his job.
> 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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
> 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.
He seems to be talking about some specific type of C++ programming.
Starting in the mid-2000s, C++ started feeling like a different language at each company I worked at. Different libraries allowed, c-style versus STL coding, even completely different ideas about how classes should be written.
I looked at some recent language proposals and didn't even understand what the code was doing. Saying "I know C++" is too vague and almost certainly incorrect.
C++ at Google is almost a different language (and nonstandard tooling and libraries and workflows). It's entirely possible to have decades of experience that don't translate to anything useful outside of Google. To give you an example: I joined Google when SVN was a thing, and by the time I left* I was a senior software engineer with zero experience using git.
I wrote a ton of C++ back in the early 90's. Should I dust off my chops and spend the last few years of my career consulting like the Cobol and Fortran people?
This is the capitalist version of Vonnegut's "everybody wants to build and nobody wants to do maintenance." The kind of programming HFT firms want to do has vanishingly low diminishing returns basically everywhere else. They're used to lazily offering high pay and bad working conditions to self-driven people who learned C++ because it was the only tool available. Now other languages are mature and they are being caught flat-footed without a development pipeline for junior devs.
Strategically I understand - it was a pretty good bet that you could use the same "get gud" philosophy that still powers their trading desks, but they just got unlucky because we're in a moment where the net opportunity-cost for not-learning c++ is basically a reward (better work experience, often better money).
Headline makes me think of RPG (the language, look it up [0]). It's basically disappeared, but it was one of the key languages used to develop much of the banking system waaaaay back. For a variety of reasons, it's still very much present but the experts are in their 70s and anyone competent enough to debug is well into their late 50s at the youngest.
Attempts at upgrading to, say C++ or Java usually fail for the same reason any massive system-defining upgrade fails, so they have to trot these guys out every now and then to the tune of $100-500K per day whenever there's a problem.
Moral of the story - sometimes it could be a better very long-term strategy to be an expert at just one language that has enough mission-critical functions in an industry that doesn't like investing in IT. C++ could turn into one.
Yes, a day. When you're dealing with a bug that could disrupt all international transfers at your bank for several days, and the kid you have on staff who learned RPG on YT has reached his limit, it's cheap.
I learned about it from a friend who worked at an IBM partner with a tool to help translate RPG to something else. Rarely worked because of the decades of nuanced patches to deal with evolving business rules, and when it did they usually came in several million above budget.
One solution would be to ask the "rainmakers" to replenish the drying pool with some "liquid means". Developers are known to be attracted to the highest bidder / latest master of the Universe.
Can't we have an automated C++ to Rust converter (with full correctness), and then add a pass of GPT3 to transform it into something readable (only correctness-preserving transformations allowed).
Personally, I would love to code in C++ but most projects are Python these days. I spent most of my career as a C++ generalist, along with doing a bit of graphics work.
591 comments
[ 3.3 ms ] story [ 374 ms ] threadMaybe that reputation has caught up to them.
I imagine some work is also useful on CPUs, and C++ is one of the most efficient languages.
But the CPU-drivers of CUDA are all C++. Albeit a C-like API (cudaMalloc, lol), but its a clang compiler for the CPU code nonetheless. If you have complex GPU + CPU interactions, you'll need to be a C++ expert.
Even if you aren't doing GPU work and sticking "only" with CPU-side CUDA, its all C++.
[1] https://www.metaquotes.net/en/metatrader5/algorithmic-tradin...
In New York City. Oh.
Compare to Google salaries, on levels.fyi for example. I know they're not theoretical or inaccurate because I worked at Google for a while. If you really want to do C++ professionally, that and maybe other FAANG companies seem like they'd give you much higher quality of life.
But the truth is, if you're a C++ developer, you may as well just take up another programming language and get paid more. The data doesn't lie:
https://survey.stackoverflow.co/2022/#technology-top-paying-...
C++ was basically the first programming language I really learned, but I seldom use it in the industry, because I don't know why I would intentionally pick a pay cut to do harder work. (I consider C++ to be "harder" than many of the languages above it in pay grade even when doing the same work, for most tasks.)
Hiring for C++ is hard because C++ is hard and most people are quite bad at writing even somewhat reasonable code.
A quick google search is suggesting that $200K for the top end of experience, when I was told $300K they said it was as high as they go. Where is the rest of this compensation coming from? Maybe they could give stats for bonuses but when enquired it seemed that the bonus pool was being eaten up elsewhere and the C++ devs were in the back of the line for that.
Often bonuses can be >100% of the salary. Bonuses vary based on firm performance. The advice is typically "Live within your salary, don't let your lifestyle creep up to demand your full total compensation". HR typically emphasizes that the bonus is not guaranteed (unless you negotiate a guaranteed bonus for some number of years [1-2] after hiring).
Also, salaries/TC have gone up in the last 10 years.
Same with the poker machines. Recruiters gotta recruit, but I’d just make my own meth if all I cared about was the money.
Also weirdly C++ devs aren't making that much more than the fullstack devs who build FOH tooling for traders.
What's the point of all that money if you have no time to spend it and the stress will send you to an early grave?
It did. Comp is nowhere near FAANG and the work culture is still stuck in the 90's.
Go to any college and talk to students looking for internships. Finance firms are nowhere near the top of their list.
The usual destinations for smart and motivated new grads are (not counting very early startups/making your own company):
1. Top tier HFT/prop firm (Jane Street, HRT, Jump, etc.)
2. Meta, larger unicorns like Stripe, Databricks, etc.
3. Google
4. Amazon, Microsoft, etc.
Obviously im leaving out a lot of places but this is generally what I've seen.
Id say for most people FAANG is still the top option, and for people that want to shoot beyond FAANG, trading firms are probably the next target.
If you were including very early startups in this list, I've noticed that the smartest people often join promising startups as an early engineer, or make their own company. I'd put them above trading firms, but the risk is way higher.
There are certainly financial firms that people are less interested in though, namely banks.
Perhaps "prestige" may be lower from an external perspective (Your parents will brag about you being at Google, but probably not Jane Street), and Id also agree with the fact that the top 0.01% probably either make their own startup or join as a founding engineer at a startup, but the top 0.1% of students are definitely going for Prop trading/hedge fund jobs.
The problem is that there's a law of diminishing returns to compensation. If you can work with a tool you like that helps you meet milestones and general expectations for $X00k generally leading to pleasant days, or can work with a tool that makes your life harder and leads to higher stress fewer pleasant days for $2X00k... sure there's going to be people who take the extra money. But there's also going to be people who say to themselves "yeah, it turns out I'm plenty well compensated at $X00k I'll take the extra quality of life."
"Worth it" is a value judgment. How many people managing the financial firms decided it was worth it to invest in C++?
It's not the language, it's the extremely toxic culture. Any programmer worth their salt can march into a nasty codebase of whatever language, and make it dance. But financial folk don't want to employ humans with all their complexity, they want robots who will run themselves into the ground for cash. So they get young men who burn out quickly and retire ASAP. The problem isn't the language. The problem isn't the pay. The problem is the extractive culture. Finance folks focus on short term profits to the detriment of their future. And now they're wondering "where can we find programmers" after they've been burning them like so many trees. Go figure.
Correct, I wonder why people both technical and non-technical focus on this aspect a lot. ( my guess is that they are incompetent themselves).
Agreed, if you want someone for two or three months you probably want someone who knows the language and it's ecosystem pretty well. Any work that is more than six months should be nearly language independent.
I'm not sure this is true in finance. Speed matters. A lot. It's called high frequency trading for a reason. These firms will spend a million bucks just to make their fiber optic cables 1 foot shorter.
So if it's not 6 months, how much will it take for a seasoned programmer to learn the stuff?
Working at a bank / prop firm is going to be extremely stressful. Working at the shop that all the big banks buy their trading software from is like 80-90% of the pay but none of the stress.
I love it. I get to do real, hard engineering for big pay without working on ad tech or javascript.
There's more to the story than just comp. Even increasing comp wouldn't immediately generate new developers, as it takes a very long time for the increased comp to incentivize new students and junior engineers to move in that direction in their career.
High performance C++ takes a lot of time and effort to learn, and even longer to master. Maybe the real issue is that there has been a surplus of high-paying jobs that are much easier and require a lot less effort to master.
Also you don't have to only incentivize grads. Getting experienced devs to jump ship is the primary goal. Which a $100k+ raise would certainly incentivize.
I despise the language, 80% of my time is spent figuring out how to beat it into submission to get it to do what I want, which leaves very little brain power left over for designing well architected software.
Modern languages get easy access to a large number of powerful design tools, C++ I have the same tools but it's stuck behind an interface (headers, the build system) originally made in the 70s.
But also, these companies have a lot of weird modern C++ shibboleths in their interview processes. If they compromised on those and went for low-level engineering, performance engineering, and software engineering skill instead, there would be many more candidates.
When fresh out of college, I used to pride myself knowing C++. I used to revel in its complexity because it made me feel a cut above the rest. How naive & stupid I was.
I have not worked in C++ for a long time, I cannot climb the mountain of complexity again.
Python still has a lot of C extensions and C code but Python has never strictly cared about C++.
From a Python perspective, at least, C++ is more like COBOL than FORTRAN.
Articles like this are nothing more than a desperate attempt at getting younger generations to learn said topic, so companies can pay them crappy salaries.
Note the C/C++/C#/SQL cluster at $70k/12years of experience.
> Wt is a web GUI library in modern C++. Quickly develop highly interactive web UIs with widgets, without having to write a single line of JavaScript. Wt handles all request handling and page rendering for you, so you can focus on functionality.
https://www.webtoolkit.eu/wt
HN submission: https://news.ycombinator.com/item?id=23812791
I actually doing all web backend using C++. I do not render to HTML though. All JSON based RPC. Rendering done by front end JavaScript.
I get paid very well doing embedded firmware dev, but that’s because we don’t make money on our hardware, we make money on the software that it talks to for industrial IoT analytics
Is the entity you are selling your services to earning a large profit margin? If yes, then it is possible (but not guaranteed) for you to earn more. If not, then look elsewhere.
Generally, this situation happens in businesses that can scale with little to no marginal costs (software, media), can use governments to defend its property (intellectual property, land), and can be easily used as collateral (land) with which you can obtain leverage (money).
1. A lot of the tooling is made by the hardware suppliers. Hardware suppliers tend to be very bad at writing desktop software; I have some theories as to why that is, but no direct evidence for them.
2. When tools are selected, they are rarely evaluated by software developers who will be using them. It's more like "Here's a list of boxes anything our development tools need to check" and then the final selection for anything that checks engoubh boxes is done for business reasons (cost, likely availability of support down the line &c.)
3. The same reason that embedded developers are often paid poor salaries; for a lot of hardware companies, the firmware development is treated more as a cost-center than as something that generates revenue.
I had a large group of devs I used to hang out with. It was about 50/50 front-end and C, C++ guys. Over the last decade or so, every single C developer either transitioned to PHP like yourself, or went the full-stack JS route and have never looked back.
And it was all over the issues around dealing with legacy systems and the poor pay. One guy told me flat out he can make close to twice as much being a very in demand JS developer with great benefits and reasonable hours compared to the horror show of working in government (military) or finance.
Think about how web companies can have very low up-front costs, use a cloud provider and some high-level frameworks for python or JS etc, make a stupid social-media connected app, and start making big money (or get investments assuming they will after capturing many users).
Then think about hardware companies - it's a very competitive space, it's mostly a commodity, the high-level software doesn't care so much about the specific chips providing those cores of cpu and gigs of ram, and what's available on the market is really amazingly powerful at a really amazingly reasonable price, due to competition with other providers in the market, and with older hardware!
It does seem kinda perverse, but ... the closer you are working to the hardware, the cheaper the market for your work, but the further up the stack, the more potential for high pay, based on the higher monetary efficiency of those companies, by running very in-efficiently on super-competitive hardware, and differentiating with features and services etc.
It's really not worth it
I used to work for an industrial company in the defense sector. We were working on very complex problems with difficult requirements in term of resilience and performance. It was extremely interesting: complex algorithms, redondant architecture, hard real time development, most of it in C++ or Ada. Deadlines were tight. It was quite stressful and the pay was miserable.
I left the field entirely but most of my former colleagues now work as fullstack developers for companies building SaaS solutions. They all complain about how boring it is but they all have doubled their total comp.
Meanwhile, I heard from my former boss that the company still complain that the part of the org doing software is more expensive on average per employee that the ones doing production (apparently no one has realised we don’t hire blue collar workers in this part of the company) and keeps grumbling about how talent is too hard to retain in my city.
Just how much can a skilled JS dev get paid?
In general, the big cos hire maybe 1 JS dev for every 2 or 3 backend devs. But they're on the same payscale. From what I've heard, it's more challenging to climb the level ladder, but if you come in at a terminal level and aren't particularly interested in that stuff, it's pretty comfortable.
Midwestern state, large health care company - between $150-$200K (this is FTE status with benefits)
You can also be a contractor (hourly, no benefits) and squeeze a bit more out and just jump around from company to company. Senior JS devs are in seriously high demand right now. I get around 5-6 emails a day from recruiters looking for Senior JS devs.
Most of FAANG backend infrastructure is written in C++. Lots of open positions as senior folks retire early from there.
There's less C++ devs, C++ is harder, demand is still high. Why are the salaries low?
If I am a C++ developer, in my late 50s, close to retirement, and know C++ fairly well, don't want to learn a brand new system which I won't be coding in for much longer, and already have my financials all set...
I won't be looking for that early retirement big cash payouts. I just want my flow of cash for a good retirement, to go on my vacations, and to buy gifts for the kids / grandkids.
I'd be willing to settle for a lower pay with low stress and solid job security.
Remember the desires of people later in life and those early in life aren't the same. If you got 10 more years of work left, you don't want to be in a high stakes high intensity work environment. I worked with one such man. He'd fall asleep while coding mid day. Nobody bothered him. He just chipped away at his projects at his own pace and was happy to not be bothered.
Sounds like such a company is looking for a boomer/genx who's still got skills and willing to settle for not being bothered too much.
COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Are there other sources (articles, research, blogposts) that talk about this?
> COBOL got to where it is when there stopped being entry level jobs for it. Videogames keep a massive entry level door (full of "passion") open for C++. That's going to "naturally" keep C++ development salaries low for the foreseeable future.
Not anymore.
I am frequenting gamedev forums, and reading gamedev chatter in general (seeing youtube videos on game conferences, presentations on games development, etc).
Maybe 1 in 10 of the people in these gamedev places actually program in C++. Mostly they'll use Unity (C#) or Unreal Engine Blueprints, with some Godot getting popular and a few statistical-noise engines being used (Love2d, etc).
What you are saying used to be true; on gamedev forums almost everyone used to be able to program in C++. Now very few do.
Yes, Unity is the default engine in the indie scene, but what are EA, Ubisoft, Embracer, Take Two, etc. hiring people to work with? Because these are the meat grinders who hire fresh college grads by the hundreds and work them like oxen until they burn out.
I wonder how many programmers are used at the AAA publishers. Maybe someone on HN who works as a gamedev (ISTR one or two people in the past saying that they worked for AAA developers) can answer that one.
(As an aside: I've got my eyes on FNA which just hit some milestones with using .NET 7 AOT for pure C# games on the major consoles. That's pretty exciting.)
Unreal is the truly wild one because to my understanding Unreal Engine Blueprints are a terrible half-baked not-quite-scripting language and most Unreal developers have to do most of their "proper" scripting in C/C++ directly. (With some statistical anomalies allegedly doing things like bolting in Lua interpreters.)
But yeah, outside of indies and small game companies my impression is that C/C++ is still king and there's some consternation that developers learning from the indie side are sometimes, if interviewing for AAA teams, getting shuttled to "tools" positions because that's where AAA's only C# code lives (in non-critical tools outside of the games). (Though that's mostly anecdata from reading similar gamedev forums.)
There are pockets of the C++ ecosystem where this isn't true (e.g. HFT).
But bottom-line, it's a business thing, not a skills thing. There are also a lot more C++ devs than the zeitgeist would suggest. Far too many to cause a "COBOL effect" where supply constraints on talent dictate market price.
Indeed, many businesses correctly decide there's no benefit to using a difficult tool that isn't required, and choose an easier tool that produces a better business outcome.
e.g. suppose you're a non-tech enterprise (bank, utility, etc) and you need to build a bunch of backend web services to support your internal operations. If you decide to implement them in Go, which is arguably a domain specific language for building web services, then you can probably deliver the project by hiring a bunch of fresh grads and putting one intermediate to senior programmer in place to lead the effort, even if no one has any Go experience.
arguably if you try to deliver the same business outcome in a random enterprise context using C++, a project team will likely have a far more difficult time getting basic HTTP / TLS server stuff in place, and if there's lots of rookies on the team, they'll keep making foot-gun memory error mistakes.
Sure, maybe if it was built in C++ by highly senior engineers, and subjected to a thorough QA process, you could end up with a system that's much more efficient at runtime than what could be cobbled together by less experienced engineers with an easier language and a good standard library. But in most business settings efficiency isn't the bottleneck, it's delivery speed and then maintenance costs, which are driven by staffing and how expensive it is to change the code each time the requirements change.
Sure, and a scalpel is a lot sharper and more precise than a lawnmower.
Which one do you think will result in more expensive lawn maintenance?
Not really. I've spent more time debugging JavaScript than debugging C++.
It used to be hard. Modern C++ is actually a quite pleasant language.
The issue is libraries. For example, one very basic functionality of any programming language is DB connection.
In particular, MySQL is very widely used. The C++ libraries (c++ connector) are older, less maintained and just plain broken in the last Ubuntu (it's Oracle's fault, and that can't be helped). They are more stable in Python, for example. The reason is trying to force SSL, reading the source code of the C++ connector it's clear it was intentional.
So, for many things that should have a well maintained library, there's actually not a good C++ one. Web servers are another example. There are only one or two libraries, very opinionated and with "proprietary" widgets, and that's it. Nothing comparable to Laravel or FastAPI.
In other words: the language is fine. C++ is a fine language with a fast runtime, and modern practices and implementations are pleasant to use. It's the disregarded ecosystem in C++ the one that needs improvements. Libraries, package management, build systems, etc. Even then, for performance, some things are only available in C++.
SHOW ME THE MONEY. I'll be a C++ programmer.
Labor supply stories never talk about salaries. I can also see lots of references to embedded and close-to-hardware jobs, which means low salaries, unsexy code, and flawed/buggy toolchains compared to mainstream platforms.
It's right there in the article: "demand". Why do business people pretend basic supply and demand first day microeconomics 101 doesn't exist as soon as you say "labor"?
I suppose this is more fuel for Rust adoption. Rustaceans, is the war won?
Btw, it is INSANE that we pay engineering positions (you know, real ones like electrical/hardware/materials) so poorly compared to software devs. Engineering has professional organizations which, like the AMA, should be able to enforce some degree of good pay.
On the other hand companies with steady profits and little growth have no such expectations and try to pay as little as possible for the software engineers they do need.
The only well paid embedded jobs involve producing weapons ('defence') or gambling ('gaming'), and I'd rather sell crack to kindergartners while also prostituting myself than do that. I did get a bunch of those offers and still do get them every now and again, even though I'm happily employed.
Moved to finance, never looked back. People should plain refuse to work in embedded, maybe then thing will get better.
Also, C++ is the differentiator. People hire for other languages (C# and Rust, in my experience) based on your deep C++ knowledge. And this does make sense, this is a great proxy for your development skills and potential.
I interviewed for Amazon for an embedded/mixed role because that was my forte at the time, and the compensation offered was nothing special, worse than even a mediocre finance sector offer, much better than automotive or general embedded (medical, industry / robots). Could never get an Apple interview (they passed on me twice), though, and I never even thought about the rest (that would require relocation to to places I don't care about).
But since I never actually worked for those companies or have any concrete data I could be completely mistaken. I only have friends working in FANGs in non-embedded roles and embedded friends only working for shit-paying companies, plus some of them are not willing to discuss salaries (suckers). Also, I get the feeling that AMD / Intel / Nvidia operate a bit different than the rest.
Do you know the reason for that? EE is significantly harder to learn than CS, so it baffles me why more people are choosing EE.
I wanted to get away from physics so I ignored that, and in hindsight it was 100% the right choice. But the advice was well intentioned and I considered it.
But yeah, fully agree with you and parent comment. And no, it is not worth it
While naturally CSs don't know about Analog or GHz stuff, EEs know very little about best practices on SW development. So it kinda balances out
It may be because EE is older and more entrenched, or because of ties with the industry. Engineering of any kind has centuries of prestige, historic industrial support, historic large buildings and grants, etc. I would bet on the comparative ease of hiring staff for EE, though. It does make some kind of sense for some academy-prone people to go the academia route in EE. Especially if you sprinkle in some industry side-jobs, because the industry side is not that cushy by itself. This likely makes it easier to staff EE faculties. For CS, academia only makes sense if you have direct industry support (like doing machine learning w/ direct support from a FAANG), and you can expect something like that in very few places in Europe (Zurich, London, maybe Amsterdam?). Otherwise, you really have to hate making money and being respected to get into CS academia. There's a distinct lack of staff for CS, and they let anyone be assistants (at least they did half a decade ago). I remember there being some competition for math positions, and a free for all in CS. Some smart CS people do get fooled into joining, and last around a year until they see it's a waste of time. No amount of academic benefits in later life can offset the accumulated difference in pay.
As an actual failed EE student (moved to CS after 1 year of EE an eternity ago), I definitely agree that it's way harder. I even think that it's not just my affinities, but it objectively requires more effort and is more dense with difficult stuff. What's ironic is that the (officialy!) best EE student of that generation is now a Rust dev for some crypto company (last time I saw him on LinkedIn).
My personal experience also says that you spend much less time to build something profitable in JS and PHP than in C or C++.
I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up. Hopefully as a result of moving to languages like Rust - it would work out best for all developers. But it's not looking good in the C++ land salary-wise now.
Maybe. I've made the jump from pure embedded (spent over 15 years in embedded) to backend (Go, with some rudimentary Java thrown into the mix). I literally doubled my salary in the space of 12 months.
In 20 years, are they going to hire my retired old ass to make their codebase live another 5 years longer, or will they simply bite the bullet and rewrite?
> Hopefully as a result of moving to languages like Rust - it would work out best for all developers.
It could happen, but I'm not that bullish on that happening:
1. No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety[1] - the end result of using Rust on a 2kb RAM/8MHz chip (atmega328, or xmega, or one of the stm32s, for example) is going to be using unsafe everywhere anyway.
2. High rampup - the majority of knowledge needed for low-level comes from EE, not CS. Already Rust has problems with adoption amongst CS people, who (in theory anyway) have all the requisite knowledge and motivation to climb the learning curve. I'd bet money that EEs won't even bother looking beyond the awful syntax.
3. Better alternatives - all those higher-level embedded projects such as RPi, Beaglebone, etc that run Linux have better alternatives for programming them than Rust. Most custom code written for the RPi is in Python, for example. Someone looking to develop on these boards is almost certainly better off using Go instead of Python, and Python instead of Rust.
So given that there's a) no benefit on low-powered devices, b) there's better alternatives on high-powered devices and c) it's a complicated language with slow ramp-up, I'm having trouble in seeing exactly where it fits in for embedded.
> But it's not looking good in the C++ land salary-wise now.
Nope, it isn't. If enough C++ devs jump ship (and, to be honest, in low-level embedded C++ as you know it isn't used much anyway), then salaries will rise again.
The problem is, as someone else pointed out, that many of the places using C++ are shooting themselves in the foot, because they want senior and experienced people who can ramp up quickly on the latest C++ standard, but without a pipeline of unskilled/juniors, there's only a few number of years before there'd be out of any C++ devs.
And because it's not an attractive language, there's no one switching from (for example) Java to C++, or C# to C++, while there are plenty switching from C++ to Java or C#.
[1] Beyond which, it is not clear if safe Rust will ever be able to interact with various embedded OSes for these chips; most of them are external kernels anyway, so there is no way to use those kernels without using C.
Where they have enough grunt to do a lot of tasks at the same time, all driven by config over the network, with less hard real-time requirements for some tasks and stronger requirements for others.
That’s not that big a segment though, I would think. And in some ways, just chucking extra slower chips at the problem on the same board is simpler.
The Rust embedded ecosystem has lots of benefits in addition to pure memory safety, which is basically table stakes for a modern language. It gives you a vastly improved DevX, at least if you aren't using hardware that's too exotic for which only proprietary C/C++ toolchains are available.
Some of it is tooling: It's trivial to walk through expansions of Lisp macros, while the tooling for C++ is ... less ergonomic to say the least.
Some of it is a weird combination of technical/cultural. You can do a lot more in Lisp without reaching for macros as compared to C++ and templates. In addition, every CL style guide ever says "don't use a macro when a function will do." There's also the culture of "Read *Let over Lambda" (a book on Lisp macrology), now don't ever do any of that unless you absolutely have to"
I don't know if that's a solvable problem (maybe higher pay? But I hear they pay well already). Or maybe my perspective is an uncommon one. I just think it's silly to say there's a shortage of C++ devs because a specific industry has hiring difficulties. The article says that it's not a HFT-specific problem, but doesn't go into it.
Take a look there if you are looking for a useful role in the society: https://sdgs.un.org/goals
List of benefits of high frequency treading:
.
One thing I read is that memory allocation can be faster in Java because malloc can result in system calls. Deallocation is what's slower.
I decided it wasn't worth pursuing, went from doing Clojure to Big Data in Scala.
Ten years later, I hear that there's not enough "C++ developers", read, "C++ developers with the desired qualifications". Seems straightforward to figure out why.
Troubleshooting a big legacy C++ codebase is probably something that Dante would have included in his Inferno as a punishment for pride and hubris.
... with deadlines measured in hours.
Uh, but it still kinda sucks, if only because the nice way that looks idiomatic is usually the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety (operator[]).
The correct way is usual the ugly way, because it seems like the committee puts C++ arcanum knowledge above all else, instead of developer satisfaction or maintainability
At least the C++ compiler is doing actual work. And it is faster than the webpack madness.
I don't know where you got that idea from, but with an up-to-date compiler variants are safer and more performant than the traditional approach (classes hierarchies), and std::optional is safer and 99.9% as performant as a nullable pointer.
Except for it taking up twice the memory as a pointer (https://godbolt.org/z/5We9zEbvh) and it not doing anything in regards to safety when using pointers. Even if you're replacing a nullable-pointer with a std::optional you're still handling landmines when using operator* or operator-> - the most convenient ways to use std::optional.
C++ is doomed forever to have safety-third design.
you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.
C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ -
https://computerhistory.org/
I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink.
I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
that would the starlink whose performance slowly, inexorably degrades as more and more of my neighbors start to use it?
Gaming has Unreal but surely you could use another game engine without C++?
For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
bumpalo doesn't cut it. Funny thing is that boring and sensible Go just came out with arenas support.
We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables.
there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
you also need to worry about which stdlib to use in C++ - too bad!
> SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
please stop such nonsense. AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
> the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process
why this is even related to the ongoing C++ discussion? once you have the package, you need to somehow distribute it, app store, http service, bittorrent you name it. but why it is even relate to any programming language since you brought it up here?
you can probably argue that golang's stw isn't going to help when building audio stuff, but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way by rust. audio plugin or not, I don't care, in the end it is just the same machine code.
Well that's nice. What about ARM SIMD? And the M2 variant? You're suggesting that every SIMD instruction set should be accessible via the same language-invariant syntax or else a language is just broken?
> but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way
the point is that it is NOT done by a legacy language known as C++, and it should not be done by the young languages that go by any other name, contrary to your claim that essentially everything should be a part of the language/compiler/toolchain itself.
This is, obviously, a very opinionated opinion.
If I was going to be forced to do it, this is how I'd want to do it.
Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C.
I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
I’m lucky ;)
I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful".
If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap.
And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero.
Polyglots truly are jacks of all trades and masters of none.
I may have exaggerated with the “nearly every” sorry!
But we do use sufficiently enough tools to avoid most of the pain of c++
If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain.
C++ gets underserved hate by people who don't care about doing a good job anyway.
C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.
Almost in every case, you'll find C++ at the core of them.
A modern project should be able to use most of C++17 at least. Even if you still need to target some ancient garbage like Windows XP, you can use an MSVC toolchain that supports C++17. That's a good basis to work from.
So your real concern is the moldy old code that's written for C++03, that's still not using std::unique_ptr or anything equivalent. If you're given license to finally rewrite that code to modern standards, that can be fun if it's not a complete mess. But if you just have to live with it, and still write C++03, absolutely not, I would never do that job.
But that's mostly learning modern paradigms of the language.
If you also mean the tooling, then it depends: Learn CMake which is sort of an industry standard. There are books and videos, but for a concrete experience, try looking through the CMakeLists.txt of some non-trivial C++ open source project.
Probably the best resource for CMake modern best practices/ rational of those practices.
Most tutorials online are outdated, CMake documentation is hard without a firm mental model of how it works.
You say that like there's one for a project but I've been learning Blender's codebase and every folder has a CMakeLists.txt. What gives?
Use clangd, clang-tidy, cppcheck. (These will tell at you if not using best practices)
Use the stl as much as possible (or at least make "would this work using stl" your go-to question.
Write a vector with iterators from scratch in c++20
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?
It's not like C++20 is completely different. There's just a lot more utilities in the stdlib so hopefully less raw pointer magic.
What was best practice for C++03 is not the same for C++20.
Switching a codebase from C++03 to C++20 for a nontrivial codebase means changing design so radically it may as well be a new project, rewritten from scratch.
It'd certainly be easier to rewrite in C++20 for the C++03 projects I've recently worked on, than to try to squash in a C++20 design.
- Immature compiler susceptible to generating performance traps
- Build times even longer than the infamous ones in C++
- Simplistic declarative-based build system
- Inability to opt-in or to opt-out from static analysis
- Harder to scratch up quick PoCs because borrow-checker
- More complicated compilation model making it harder to understand, debug and implement workarounds when codegen goes south
- Much smaller ecosystem - libraries, toolchains, tools, ...
- False sense of security - by default it relies on the ecosystem whose runtime and its OS is implemented in "unsafe" languages
- Cannot even live to its "safety" promise because hardest problems cannot be solved without unsafe sections
I sincerely wish it was different but at this moment I am not convinced that Rust trade-offs are worth switching to it. This is the PoV coming from a system-level programming, very close to the OS, and with a lot of difficult memory and concurrency scaling issues.
I spent two months asking one guy who knew about it for help. I really understood the concept of "hostage taker" in a software team. It's the guy you cannot fire and will constantly arm-wrestle everybody where there is a problem, never really helping, and continuing to write bad code that allows him to keep his job.
Fortunately they did not hire me.
I never was so discouraged in my life.
I don't understand this, where you working for free?
Last couple jobs have been heavily legacy C++ in the energy sector.
Lots of maintenance, but also opportunities to overhaul and build new objects.
Funnest project right now is porting some supercool Science code to cuda and getting about a 30x speed up.
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.
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.
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.
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.
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.
1: https://www.stsci.edu/~idash/pub/dashevsky0607rcsgso.pdf section 3.1
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.
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?
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.
It's better to be a specialist in JavaScript + crypto than forth.
If crypto doesn't pan out, you're still a JavaScript developer that can get a non-crypto job.
If forth doesn't pan out, you have to become JavaScript developer to get a job.
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.
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
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.
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...
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.
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.
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.
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.
Starting in the mid-2000s, C++ started feeling like a different language at each company I worked at. Different libraries allowed, c-style versus STL coding, even completely different ideas about how classes should be written.
I looked at some recent language proposals and didn't even understand what the code was doing. Saying "I know C++" is too vague and almost certainly incorrect.
* I have since re-joined
[Only half kidding]
Strategically I understand - it was a pretty good bet that you could use the same "get gud" philosophy that still powers their trading desks, but they just got unlucky because we're in a moment where the net opportunity-cost for not-learning c++ is basically a reward (better work experience, often better money).
Attempts at upgrading to, say C++ or Java usually fail for the same reason any massive system-defining upgrade fails, so they have to trot these guys out every now and then to the tune of $100-500K per day whenever there's a problem.
Moral of the story - sometimes it could be a better very long-term strategy to be an expert at just one language that has enough mission-critical functions in an industry that doesn't like investing in IT. C++ could turn into one.
[0] https://en.m.wikipedia.org/wiki/IBM_RPG
Do you actually mean 100-500k per day?
I learned about it from a friend who worked at an IBM partner with a tool to help translate RPG to something else. Rarely worked because of the decades of nuanced patches to deal with evolving business rules, and when it did they usually came in several million above budget.
Maybe if you quit Citadel to create your own company you have to be prepared to pay like Citadel for the same quality of people.