The pool of talented C++ developers is running dry
efinancialcareers.com
efinancialcareers.com
I interviewed at a trading firm once, while I was working at Netflix (because Netflix encouraged us to interview for outside jobs at least once a year). The comp would have been double my Netflix salary.
But I would have had to work in their office in Manhattan, be in by 8:30am every day and not leave until after 5 at a miniumum. But that wasn't the part that scared me off. It was the fact that I would not be allowed to share my work internally. I would not even be allowed to brainstorm with people doing the same job in other areas of the business. I wouldn't be allowed to take my laptop home, so if I had a hard problem to solve, I'd have to stay in the office the whole time. So basically they expected us to never see our family nor collaborate with anyone.
Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies, they didn't even let people share internally for fear that one person would learn too much about their business.
I decided to stick with my FAANG job because even the ridiculous money wasn't enough to make it worth the stress and isolation.
This is what Apple does as well. So not all FAANGs are equal here.
If you're doing general quant library or low latency stuff at an IB I wouldn't say this wouldn't happen but I'd say it's definitely not common.
Can you tell us more about this? What's their reason for it?
In the fall, your pay was evaluated (and kicked in at the new year). You were paid on the assumption that you were a top performer (otherwise you would have already been let go), so they would adjust you to "how much would we have to pay them to get them in the door today". They needed data for that calculation.
One source of data was how much they had to offer new hires to get in the door. A second source was industry salary surveys. And a third source was your offer letters from other companies, if you chose to share them. If you get a huge offer elsewhere, they would maybe match it, or maybe tell you that you're better off going to that other offer.
It also served another purpose. It gave you a chance to look at that other offer (assuming you could get one) and really thing about whether you still liked your job at Netflix enough to stay. They wanted people to be happy about continuing to work there, and were supportive of you leaving if you weren't happy, because they know you do your best work when you enjoy it.
FWIW, my raises at Netflix were typically 20%+, and so were a lot of people, because they economy was on fire at the time.
I've heard about the culture of fear at Netflix - was this your experience as well? Who decides whether you are a top performer or not - only the manager, or the peers as well? Do they use stack ranking? How is the performance deduced, e.g. by nbr of commits? Thanks!
> I've heard about the culture of fear at Netflix - was this your experience as well?
At first yes. But you quickly realize that in most cases only the underperformers were let go. In cases where good performers were let go, it was usually by a bad manager, and then that manager would get let go and they would sometimes even offer the other person their job back (but they usually already had another one).
> Who decides whether you are a top performer or not - only the manager, or the peers as well?
You manager has final and single say on both hiring and firing. But they always ask for input from others as a matter of course.
> Do they use stack ranking?
Absolutely not. Stack ranking is the opposite of what Netflix believes. They operate on the assumption that if everyone were stacked ranked, everyone would be in top rank. Stack ranking is evil and a terrible way to run a company if you use it for determining compensation or firing.
> How is the performance deduced, e.g. by nbr of commits? Thanks!
Haha no, no metrics like that. It's much more holistic. Are you getting good work done, are you making a positive difference. Managers are pretty in tune with the work getting done. Most come from engineering backgrounds and at least understand the work being done by those that report to them. They also can see all the feedback in the annual feedback session. It becomes pretty obvious who is not performing.
I guess this is rare - the detection of such cases, since the bad manager's manager has to be aware. Also, the holistic evaluation makes things hard to argue - subjective opinions prevail.
If "top performer" is defined as, say, 90th percentile, does that imply >90% turnover?
Think of it like a sports team (which is how Netflix always described it). They wanted the best people in the league.
Btw, can Netflix please put some of that capital in to better programming, or at least in to adding a "Delete + never show me this or anything like this every again" button. Platform is a pile at this point. No offense
I'd go from 30k to 100k regardless of work conditions, but not from 350k to 700k.
Like, if you'd put a button in front of me and pressing it would undo it like it'd never happened, I'd have pressed it without hesitation. And they weren't even working me long hours or being outright mean to me or anything, the place and the work were just dreary as fuck and it was making me feel like shit even in my off hours.
I had another job by month 4, and took a pay hit (though not all the way down to my prior level) to get out fast.
Any engineering job paying double Netflix comp is going to have very high expectations about hours worked and rate of delivery.
And the comp package I turned down was about $700k at the time, which was 10 years ago. Nowadays it would be a $1M+ job easy.
But not seeing my family is not worth any amount of money to me, since there are other jobs for a lot less that let me see my family and live plenty comfortably.
And if was a blue collar job you got overtime. This job expected you to work onsite 80 hours a week.
A c++ developer requires a deep focus that a typical business 9 to 5 role doesn't
No manager in their right mind would trust code from utterly exhausted people written after midnight to manage billions of dollars of capital.
1. It makes no correction in how an irrational institution is run that first level managers are rational. It just means they are stressed.
2. I met him at a language meetup for another language, he wanted out but would have trouble making half his salary.
(If you wanted me to trust code written by interns and reviewed across distance and language barriers, C++ wouldn't be my first choice, assuming I got a job in banking management, how likely would it be that I could change anything about that?)
And those people that work months away from their families -- they're being abused too. You'll notice that the owners of oil rigs aren't out there with them, for example.
That’s what you said originally, which reads as mostly normal work hours, plus maybe some overtime.
If it was 16 hours a day, then please say so.
> I wouldn't be allowed to take my laptop home, so if I had a hard problem to solve, I'd have to stay in the office the whole time. So basically they expected us to never see our family nor collaborate with anyone.
The part you highlighted says you cannot work from home. That’s unrelated to the number of hours they expected you to work.
OP could have spelled it out, but in any communication there is a level of shared knowledge.
When you read a comment that you understand to be complaining about making nearly a million dollars whilst working 9/5 in the office, a more charitable path would be to examine your own context and shared knowledge, rather than exclaim loudly that OP is a bad person.
Not that you did that, but others have.
A blind spot, I suppose; I have spent my whole working life in the West Coast tech industry - though discussions on this site generally seem to share that cultural context.
Not the person you're replying to, but I was not aware. I guess we have a different cultural backgrounds and some things that are obvious for most of this website are not for me.
Also this makes me even more confused. So OP actually expects being pressured into working overtime (irrelevant where - at home or in the office)? And that's not even their main issue?
What's the point of getting a double salary if you have to work twice as much? Can't they (as a great software developer with a strong work ethics and a good work-life balance they clearly have) just... refuse the overtime?
Re-read your original description again. Nowhere did you say you had to work 16h a day.
National security is different because the rules are imposed from the outside. These are self imposed rules.
Also most defense contractor employees don't work that much overtime and many can take the non-classified parts of their work home.
Umm... wat!?
Sure in theory he would be able to retire sooner etc, but retirement isn’t such a big deal if you don’t hate your job. Also, savings compounds so saving 3x as much doesn’t mean working 1/3 as long especially when you consider social security benefits etc.
I work on a software used (not exclusively) by the USA armed forces.
I work from home for the most part. I can do that while travelling as well but I have some limitations on which countries I can do that from. But I'm not sure of the entire list.
Edit: saw your comment it was actually 80h/w onsite. That is abuse but hey the pay is great.
Silicon Valley sucks :)
But now I have choices, and wouldn't choose that choice again.
That is fine and, tbh, a very healthy attitude. But it is not abusive in any meaningful sense of the word because it is not a worthwhile tradeoff for you personally.
I feel like software development is one of the activities that are difficult to estimate. There's scope creep and sometimes all sorts of deadlines for compliance or feature rollouts and so on, so the actual workload can vary a lot.
Not saying that's okay and shouldn't be considered a planning issue, of course.
In this day and age, in this day of robotics, AI and 1% of population in agriculture, to have to work just to eat and be sheltered is abuse.
It's a radical idea, I get that. Maybe one day it will be seen as a truism, or common sense.
Once food is taken care of, a great pressure would ease off and people would find themselves with more money, which then might be exchanged to less work.
Same reasoning can be apply to housing or even to medical care. The people who build houses would get the best spots for new houses, or the rarest food, or social recognition and status. And so the medics, teachers, etc.
This can't and won't happen in a day. There are many gotchas and unforeseen problems. But we can start working on it and planning and taking small steps towards this goal. It doesn't have to be all or nothing: it can be, for example, 1 hour off the working day every 5 years, for example.
It was certainly a memorable experience, but one I never wish to repeat.
It was my understanding that was the bare minimum, corresponding to times when workload was low.
Crunch time would naturally go way beyond that.
Not what I describe decent working conditions.
Basically, they were so worried about secrecy of their trading algorithms and people sharing them with other companies
Which means if you took the job they probably would have had you sign some obscene non-complete/non-solicit/non-disparage/non-roll-your-eyes-at-them agreement. Despite the dubious enforceability of these, especially in some jurisdictions, you would still likely experience a lot of stress and expense (i.e. lawyer-up) if your departure rubbed someone the wrong way. Your exit from the trading world could involve: - demands to keep them informed of what you were doing
- private investigators checking in on what you are doing
- threatening legal letters
- or actually being sued
And that's if you did your very best to follow the non-compete agreement. If you were actually taking employment in a field remotely related to finance, you could have the DOJ/FBI knocking on your door to investigate trade-secrete theft.EDIT: And another point about "double the comp". The comp structured so that 75% is a discretionary annual bonus payout (with claw backs), and your base salary is 25%. So you could actually end up making less money, depending on the whims of the markets and/or internal politics.
But you aren't wrong about the industry in general. It's crazy frustrating.
That's probably because you worked somewhere with decent employee protections, since it sounds like you worked outside of the USA.
It's like a start up / small company culture with great compensation - you have a direct impact very easily and it's obvious when others aren't pulling their weight. The one I joined had 10 hours a day (8-6) in the contract, but no one worked more than 8 hours in the office and they actually had very flexible hours as long as you delivered.
FAANG pays well but it is plagued with big company issues which can be very frustrating to talented engineers who just want to get stuff done.
I did crazy things when I was younger, and I would NOT subject myself to those now, so yeah - abuse.
And those C++ automotive jobs in Germany? Sorry, I'm not even going to interview for 70k€ annually.
I'd take that job in a heartbeat. Working on cars? Check. Nice European country? Check. Work-life balance? Double-check. What's not to like?
Maybe it's because I'm looking for fresh graduate jobs, and 70000€ looks very attractive to me, even with a 35% tax.
The grass is always greener on the other side. :)
If you don’t like the idea of living in San Francisco or Chicago, you’ll hate it at most of the large European cities.
Small towns are a different manner.
Make no mistakes, I don't have any illusions about cultural differences and am perfectly aware of grass-greener-on-other-side syndrome. I just don't want to be stuck in a 700 km^2 island all my life.
The pay & the taxes, mainly. It is more fun owning one of those German cars than helping write their software.
> Maybe it's because I'm looking for fresh graduate jobs...
If you are just starting out, observe that the point of a job is to make money. Give serious thought to finding a job that pays well. Most people you see are working solely because that makes them money, although optimising $/hr is usually not something people regret.
That's probably actually required though.
There's a book called 73 Rules of Spycraft by Allens Dulles and these are obviously relevant for financial trading:
Rule 2, 3 and 4, are I think, the relevant ones in this case. Especially 4:
>No matter how brilliant a given individual, no matter how great his goodwill, if he is lacking in security, he will eventually prove more of a liability than asset.
First, those 8-5 hrs are only stated by your contract. Everybody on HN complains that "unlimited" PTO obviously does not mean "unlimited". Same as your "strictly " 8-5 working hours. There is a high level of peer pressure to get things done immediately.
Working in a mid office role, I frequently had front office at moment's notice ask to implement complex deals while trying to understand their vague descriptions of said deal. Now I have to spend an hour with them to parse out what they want. Good luck trying to have a mutual conversation with the front office in a high stress situation. I had to once implement a completely new computational feature to the code base in two days just to accommodate a single deal. And don't dare think that you can get into flow...
So not only can some of these deals have long compute times, but then you have front office analysts pinging you every hour to see "how are things shaping up" and if you have something ready.
Not only do you have your own tasks set by your direct manager, but you have several analysts on your ass that could drop a complaint at any second. In the end, you have multiple bosses. If they are unhappy with how fast you are delivering, you can bet your direct report will one day hear about it. There goes your performance review and year end bonus.
Now not only do I have multiple people at work on my ass, my family is pissed that Dad has to work late this evening because he was given something to work on that needs to be delivered asap.
Don't get me started on the snark by the back office. Not only can get shit on by front office, but the level of unhelpfulness by the back office made shit roll down from all sides.
You did the right thing for you and your family.
I can remote work, or remote connect to solve a hard problem, there's ofc a way to change these. As for sharing code internally, yeah, I fight for it and I get it (I m a Java dev and we need to reverse a lot of old C++ that the OGs gatekeep, takes lots of escalation to breach the "need to know" BS).
I think you can largely lower your salary to get a more junior position with no stress: I was a team lead working 6 to 11 in a startup jungling with timezone between mexico and Indonesia, and I joined the investment bank as a junior idiot for a cool 20% increase. And I refuse promotion, why do you think you d be forced to take the money and the pressure ?
With all due respect you don't know what you are talking about. This doesn't represent my 15+ year experience in that domain.
> But I would have had to work in their office in Manhattan, be in by 8:30am every day and not leave until after 5 at a miniumum.
Must have been a back office job because that's not early enough for trading hours.
- Guy says he turned down a bunch of money for work/life balance reasons
- Nah
- Guy has to respond to dozens of nay-sayers telling them he was perfectly happy with his current dump truck of money thank you very much
And he complaints about abuse while working for... AMAZON. Seriously? The irony is palpable here.
I have yet to hear the stories about Citadel firing workers because they took a bathroom break.
You: “This is OUTRAGEOUS! Hard pass.”
We sw devs can be a spoiled bunch sometimes.
You are responsible for a trading system that's turning over hundreds of millions a day. If you're not in the office by 8am or whatever, that's not a "hey you were a bit late this morning" - it's a major "wake up the CEO the engineer on call is not present and we're not trading"! It's BAD. your train ran late? Doesn't matter, you're responsible. Your boiler exploded? Leave your house flooded, work comes first.
It's EXTREME pressure all around. I've done overnight support for a fairly infamous quant fund and I'm still on medication 5 years later because of the anxiety disorder I developed whilst working there. To this date the Blackberry ringtone triggers a PTSD response and I get physically sick if I hear it.
I spoke with someone recently who is in sales for a large finance behemoth we've all heard about and even that person was like "Goldman is the worst, I'd never go there."
But, most developers in quant roles, or close to quant roles (trading infrastructure, research support, etc) do not experience anything like this. On call is rare for these positions and they have regular work schedules with normal hours. Plus the compensation is multiples of what someone in an overnight support role will get paid. You probably know all this.
I was at Man AHL for 5 years after leaving GR and that is a pretty laid back company in comparison. I was not on a trade critical team per se, but some of our system were used for pre-flight checks. As such, if there was an issue the on call person got called at 5 am to sort it out. If not resolved within an hour or so, the cio/cro got called and had to decide whether to trade regardless or not. Thankfully not a common issue but definitely at least a call or two every time you did support.
Maybe it really isn't for you. On the other hand I've worked in this industry for 30 years, and done those hours, and longer, for 30 years, and enjoyed more or less every minute of it. I've flown all over the world, and been to various events and conferences that I would not have had a chance to do in another career.
I'm not clear what 'abuse' you think you're going to get. We are in a fortunate position in life actually, that we're developers that can change jobs on a whim and there's a large marketplace for our skills.
My advice to you is that you should actually have taken the role, gained some experience of a different industry (the first 6 months will be low responsibility), and if it's not for you, leave.
> It was the fact that I would not be allowed to share my work internally
I've only heard of one company that's as mad as that and they start with 'G'.
I do however share the same sentiment as the parent poster - I interviewed for XTX for a c++ role when I quit and during one of the interviews I asked about on-call rota and out of hours work.
The answer I got: "oh, it's not too bad. We have a weekly rota, you can expect to get called maybe 3 or 4 times... a night".
I noped the fuck out of that.
Others like Citadel and Jump were similar stories. Many have made offers but a combination of insane out of hours requirements and non compete clauses means I've told them all to shove it, and took an "underpaying" role to achieve some kind of balance in my life.
We were at least honest in the interview process regarding hours, there are companies where you would only find that out after starting. There were people who were willing to go through that pain and I think they would agree they were well rewarded but I understand some people want different things from their careers.
However, the moment someone would've announced that this was the reality of the situation I'd have walked out the door, because that is NOT normal under any circumstance.
I've been working in HFT for nearly ten years, in multiple different roles. I've met well over a hundred developers in the business, have at least a dozen I'd call friends, who are spread over nearly as many companies at this point in time. Most folks have had overwhelmingly positive experiences in the industry. Like anything there are exceptions, but I've seen no evidence of a systemic problem in the field. I know a few people who left my firm to go to Facebook and found it more stressful there, for instance. Certainly, I've worked with very very experienced ex-gamedevs, who would say unequivocally that developer abuse is a far bigger systemic issue in game dev than in finance.
Obviously it's fine to post your take but it should be tempered by the relative amount of experience you have.
when i interviewed for netflix i had to study their ridiculous culture document and found out it was a cult. i heard terrible stories of people being insulted openly. and you have to deal with endless leetcode bullshit interviews at FAANG which have nothing to do with your job and which disregards the years of experience you’ve built up all in the name of interviewing efficiency.
FAANG people don’t understand performance or latency anyway. they are focused on other things typically.
Tell that to the hippie pinko commies. I love trading firms and their culture. What I don't like is IBM style artificial pushing of "company values" and the kind of dystopian "sensitivity training" right out of an orwell novel.
I don't really mind working with the language and wouldn't mind sticking with it. But I don't want to work on financial software, as I don't want to mess with people's money. I work in a game development context right now, and may for the foreseeable future, but I also know that I get paid less than others at my same level in a different context. That part hurts with the way inflation has been lately.
I think in the end, those factors drive me away from trying to further my career in C++ and instead move toward something that would at least pay the bills in the future. I didn't start with C++ and could pivot to other languages and stacks as needed. But it would be a bit painful to know that I put a lot of time into this language to just not use it and let the experience rot.
This also doesn't factor in the numerous jobs that I have seen postings for that I am not qualified for, according to their description. It's hard to become a Senior C++ Engineer when no one is hiring a Junior to Mid C++ Engineer. Probably part of the lack of "talent" is not wanting to invest in cultivating that talent.
Ultimately, working in these high paying jobs lets you have a lot of great hobbies and enjoy life. Get a job with a decent work-life balance, and use the rarity of your skillset to make the crazy cash, retire early, make your own game company if you want.
The traps are convincing yourself you love your job more than you actually do, or that you don't hate your golden handcuff job and the hours won't always be this crazy...
I know a guy who LOVES his job/company and knows he's underpaid. But he's set. Has zero plans on having kids. Has his own place. 100% secure. So he can afford to do whatever. But many who have bigger goals in this economy have to follow the money.
So you're not limited to finance. Quite the opposite.
I'd be surprised if the majority of C++ jobs had anything to do with finance.
I think big tech has the same issue where they don’t want to cultivate talent. I doubt Google or Microsoft would consider me at this stage in my career because I lack a college degree.
I will say that I do get recruitment emails from Amazon, though I’m sure those are just shotgun blasted to anyone with a pulse and a LinkedIn.
Don't know for sure about Microsoft - but if you can get a referral at Google, they will definitely consider you. A college degree definitely helps you get to the interview stage, but doesn't do much more than that. A solid referral pretty much guarantees you an interview.
I went through a day of interviews at Facebook once where not even a single person interviewing me worked in C++. A lot of the interview cycle consisted of me answering basic syntax and STL questions or clarifying my handwriting which made it extremely difficult to finish the problem in the allotted time.
"Can I use AL for ArrayList?" "Go for it"
And if you think C++ is too verbose I guess you've never interviewed in Java?
Personally when I interview people I don't care about specific syntax details. I do have at least a passing familiarity with 99% of common languages though, I think only once (out of ~500 interviews) did someone use something I had never seen before.
Programming is essentially solving puzzles, so you can find the work interesting even if the topic area isn't interesting. No seven year old says "when I grow up, I want to write a memory allocator!" but doing it well, with as few CPU cycles as possible, without fragmenting memory too much, is an interesting challenge.
I wouldn't worry about what people have in their job descriptions. There's a quote from John Carmack about an ad for a Oculus dev that he technically wouldn't qualify for, and DHH who invented Ruby on Rails, was called by a recruiter asking whether he had 10 years of Rails experience when Rails was only 9 years old. A "Senior C++" engineer might just mean more than 2 years of experience with C++, who knows.
The retail financial industry, the folks like Fidelity and Vanguard that manage money for ordinary people or folks like Bloomberg that supply data for this, largely runs on Java. There are fewer foot-guns here, and you really don't want a security vulnerability that loses your customer's funds or creates an inaccurate statement.
that's precisely the bad part about it
For those who say "but I like to play video games" - yes, that's the point. Day traders like to speculate, and gamblers like to go to the casino. Your downside is capped with one-time payments, but a gambler who goes into the casino with a $20 and no other money also has a capped downside.
I do get what you're saying, but if you take it this far then literally everything sold is considered exploiting inefficacies, psychological or biological, and it's kind of a useless statement in the context of comparing markets, only useful as part of an overall critique of capitalism.
All I meant was the games industry gets a very bad rap for being dopamine driven skinner box design and it simply isn't true, and being in the industry for 15+ years I have met very few people who are comfortable exploiting psychological effects for gain. If I was in a different part of the industry I probably would have met a lot of people who ARE comfortable with that. It is there. But it is far from "running solely on" that attitude.
this close to getting it
This always fell a little flat to me (hence why I left the financial industry early in my career), but it's pretty analogous to merchants or retail. What service does a storefront provide, other than marking up the wholesale price of a good by 3x? They offer convenience - you can buy anything you want at the time you want it just by picking it up and swiping a credit card, vs. having to contract with a wholesaler for delivery, which might be months in the future, at a place that's convenient for the wholesaler, and needing to buy in quantities that no individual really needs. So it is with brokerages & exchanges - they let you buy any security with a couple clicks of a button, vs. needing to get an ISDA and pay a lawyer to write a contract, plus find someone else that wants to trade with you, plus take on the risk that your counterparty goes insolvent. And so it is with market-makers like Citadel or Jane Street: they ensure that you can always find a buyer for your securities (for a price), and that you don't have to worry that about simply not being able to sell stocks at any price.
As with advertising, when you sum up dimes across hundreds of millions of people, it becomes an appreciable amount. Particularly when you also include trades made by institutions on behalf of retail investors. Your 0.5-1.5% management fee on an actively-managed mutual fund is partially going to pay salaries for the fund manager, and partially toward brokerage commissions, spreads, etc. for the trading itself. And mutual funds care a great deal about getting liquidity when they need it, since they're in breach of contract if a flood of redemptions come in and they can't liquidate assets to pay them.
(Market makers are also analogous to the credit card industry in that a small fraction of dumb people subsidize a large number of fiscally responsible people. If you get a rewards card with no annual fee and always pay it off on time, you turn a profit, paid for partially by merchant fees and partially by idiots who carry a huge balance at 25% interest rates. Similarly, if you buy-and-hold a good stock or index fund, you're making profits far in excess off what the financial industry can skim off you. The suckers are largely made up of day traders, wage slaves who can't save anything, and underfunded pension funds with principal agent problems.)
Good post but your management fee isn't generally paying for crossing the spread. That's extra slippage.
It may show up as tracking error in the fund (the price was 10.25/10.26, the fund had to buy, it bought at 10.26 and the index trackers said the price was 10.255, it had 0.5c of slippage). But more likely the fund traded in the closing auction, there was only one price so it officially had zero tracking error, but the price was silently a little higher than it would have been if the fund wasn't buying.
I've honestly never understood this. Economics 101 teaches us that artificially manipulating supply (liquidity) is at direct odds with a free market's ability to do price discovery. If there is effectively infinite supply of any security (because all these high frequency firms are instantly hedging out the risk against their entire portfolio), why should anyone believe the NBBO? It's just a made up fantasy number at that point. It doesn't represent what the real security is worth because there are an infinite number of buyers and sellers willing to transact at any moment.
It really does feel like an enormous grift.
No, there are not. There is a limited (and not really that large) number of active participants in any given market segment, and the 80/20 rule holds among them pretty well too. Thanks to Money Stuff it dawned on me recently that market makers are not really providing liquidity. They provide immediacy. Buyers and sellers have to meet not just in price, but in time too.
The spread paid by market participants should be seen as their baked in commission for providing a very specific service: reduced wait time. We can certainly disagree about the societal value of what that service has morphed into, but the reality is that for other than the most liquid[ß] assets, participants are willing to pay extra for the ability to transact NOW, and not in some unspecified time in the future.
My personal opinion is that NBBO is an imperfect mechanism to set upper bounds to these commissions. In other words, it limits how much retail transactions can be fleeced for.
I am without a doubt a retail investor: I generate maybe three transactions a year, and I'm happy to pay something like 0.15% to 0.25% transaction fee each time, in the knowledge that I am getting a fair price at the time. To me that is a reasonable cost of convenience. My transactions are so small compared to the trading volume that they have zero price impact: in purely financial terms I could be paying a smaller commission if I set up the limit order thresholds myself - but that would take more time and be less convenient.
[ß] Read: continuously traded in very large quantities
What a market maker does is say "Sure, I'll take the other side of the trade - right now, at this price, even though I don't actually need or want the security. And I'll take on the risk that I might not be able to find a counterparty later. I trust my knowledge of the market enough to believe that the price I've offered you is one where I can profitably unload it later." And if they're wrong about gauging future supply & demand, they go bankrupt. Markets function on survivorship bias; repeat this cycle for long enough and the only market makers left are those that are extremely good at gauging future supply & demand and using it to set spot prices.
On some level, they're arbitraging risk & rationality. A retail investor makes a trade that is locally rational - perhaps they need to sell stocks to pay taxes, or purchase a home, or they've lost their job and need a savings cushion. And many of these events affect multiple people all at once (eg. everyone paying taxes on Apr 15, home sales peaking in the spring and declining in December, a recession causing people to lose their jobs all at once), which leads to temporary declines in demand that don't at all reflect the discounted value of all future cash flows of the stock market. Market makers smooth out these fluctuations, buying & selling stocks when it's globally rational based on the fundamentals of the companies and holding inventory when short-term supply does not match long-term supply.
Time shifting risk would be perfectly fine if market makers had to play by the same rules as everyone else in the market, but they don't. They get to ignore certain rules, which results in distorted prices because they can effectively accept infinite risk over an infinite length of time.
Let's say there's suddenly a run-up of $WEN and I, as a retail investor, want to short it because I think the price will surely come back down eventually. If it continues to go up, ultimately I get margin called and have a very short period of time to produce a lot of money to keep that trade open, otherwise I'm liquidated. There is a (risk * time) maximum before I, the retail investor, ultimately go out of business.
Market makers are exempt from this. They are legally permitted to short stock by conjuring phantom shares from thin air without having to locate borrows to satiate the buying demand during the run-up and wait effectively an infinite amount of time to repurchase the shares. There is no limit to their (risk * time) budget. Better yet, when the underlying company ultimately goes bankrupt from the stock being cellar boxed into the ground, the market maker can just wrap up all the worthless, sub-penny shares into a zombie holding company which lives forever, so they have never close the trade and actually pay taxes on the ill-gotten gains. Meanwhile, nobody seems to bat an eye at tens of billions of "securities sold, not yet purchased" on the market maker's balance sheet, because hey, as long as the SEC remains a wet noodle thanks to regulatory capture, they'll never get charged with fraud and the music keeps playing.
It's a system that has been deliberately structured to screw over average retail investors and concentrate wealth behind a few large market making firms, which incredulously all have their own hedge funds (which is somehow not seen as a hilariously brazen conflict of interest). Whenever anyone asks why all this complexity is necessary, the "We provide liquidity, so you can trade right now, for free!" line is trotted out and they hope you go away so they can continue running their shell game. Our markets have become addicted to this fake liquidity, which is ultimately backed by an infinitely expanding risk balloon. As long as the balloon never pops, the game is still on.
Providing liquidity a fraction of a microsecond faster than a competitor doesn't seem like real value to me, more like a cover story so that politics doesn't outright forbid high-speed quantitative trading.
Those social media companies, start-ups people do for venture capital cash grabs, Web3, and addictive mobile games all create such value.
EDIT: Okay, as the replies mentioned, OP did not make this argument. I still feel it’s valid, as a lot of big tech is neutral/worse for society, yet they are some of the loudest critics of low latency liquidity.
You will benefit from doing your interview homework first. Make sure you know the Amazon Leadership Principles by heart, try to have 2-3 solid examples at the ready of how you exemplified each one (some matter more than others), and be comfortable solving little programming challenges (I'm sure it's happened but I've never seen some of these Google-esque obscure tree challenges get asked). Lots of good Amazon interview material out there, I recommend reviewing it. Also, I hear some recruiters can help you prep.
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.
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.
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++ -
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.
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"
There's also big, legacy C++ code bases with their own idiomatic way of doing things and every faddish poor practice you can imagine from the past 40 years that'll make you curl up in a ball and cry when you face them.
That's my recipe now, after decades with C++ continuously looking to dump it, the moment I find something better. Dipping into C++ is mostly a backup plan: Numba, Numpy, various GPU targeting tools make it rarely necessary.
Maybe 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.
I do think that one of the contributing factors here is that it’s hard to be as productive in C++ as you can be in other languages. People talk about how amazing C++ is all the time and how it’s got great performance and you can build great applications, libraries, and services with it… but it still seems like the amount of work and expertise it takes to build an application in C++ is usually larger than the amount of work it takes to build the same application in another language.
The same may be true of embedded programming. The embedded programmers I’ve met seem like a smart bunch, but I know that the fact that embedded programming is hard is a double-edged sword—you need to hire expertise to get it done, but it takes more work and expertise to get anything done.
Of course, you'll get people here insisting that web dev or whatever pays well and is easy, but try asking actual hiring managers and recruiters how easy it is to find competent experienced devs.
The reality is probably that it is indeed fairly easy for some people who have a knack for the kind of thinking required. But for most people, it's not easy at all, and demand is, of course, very high.
Also doing "modern" Cpp with dogmatically ugly static and reinterpret_cast and shared or unique_ptr:s everywhere is just annoying.
"Best practices" in SWE are usually antipatterns since they are Cargo culted in a dogmatic way.
But then again I am a embedded C programmer ...
> Also doing "modern" Cpp [...] is just annoying.
You're basically saying "I can totally do what you're asking, but I actually think it's super annoying and I'd very much rather do things my own way, so you should hire me because I'm an excellent candidate." Do you expect this to be a good sell?
I am not dogmatically against 'modern' Cpp. It should just be used with self control. And many people way overdo it.
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.
Probably more like, they are turned off by how large and complex the language is, and how it's accumulating features like a giant rolling ball of mud.
The discouraging legacy lies in the code bases.
"You can just write code with new features" is a hollow sentiment, because a lot of work is maintaining legacy code, which might using all the features, from C++98 to C++17 and beyond. Old code that successive generations of workers partially modernized here and there.
There is a constant increase in how much you have to know to be a competent C++ maintainer of a legacy code base, under a modernization mandate, as long as the old parts of the code never completely go away.
Also, in the engineering disciplines we have many people with a personality that wants to know something completely. You don't know C++ if you don't know all the old parts too, and that's a turn off for someone who takes pride in being competent. You'd rather master something smaller and simpler completely, than to partially know something huge and complex.
You also don't know C++ if you don't know the new parts, and that's a turn off for long time C++ programmers who have switched to something that isn't constantly adding new unknowns.
Speaking of which, some of the C++ job ads turn away competent long-time C++ programmers by requiring proficiency in modern C++. The C++ community has harmed itself by creating a negative perception of older C++ and older C++ skills, even though those are needed in C++ work. Newcomers pick up on that and get the impression that C++ is a language that they not only cannot master, but which has parts that are frowned upon. The engineering mindset is repelled by something like that.
https://scottmeyers.blogspot.com/2015/12/good-to-go.html
The top-most entry in his long-suppressed to-do list?
"Stop trying to monitor everything in the world of C++ :-)"
I.e that retirement from C++ basically was the execution of that top-most to-do entry. Being a C++ expert means constantly monitoring what is spewing from the fire hose.
By contrast, I can be a Lisp expert and improve in that by what could be described as crystalizing. Filling the interstitial spaces.
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.
If you think you know the language - you are aiming that shotgun right at your foot.
C++'s attempts to modernize usually mean adding features with maintaining backwards compatibility. It's like adding new paint to a bucket of brown paint - things never really get better.
I think the percent of programmers who can keep the language in their head all the time is very low.
There are minefields everywhere.
https://en.cppreference.com/w/cpp/container/map/operator_at If you try to search for something in a map - and its not there - it adds it for you. If you want it to error you have to use at https://en.cppreference.com/w/cpp/container/map/at
That is just in the very well engineered standard library. What kind of code is in your company's repos? What do programmers need to keep in their heads?
Writing good C++ requires good testing, good tools, good education, good colleagues and a quasi green-field because legacy C++ is segfault...
C++'s attempts to modernize usually mean adding features with maintaining backwards compatibility. It's like adding new paint to a bucket of brown paint - things never really get better.
I think the percent of programmers who can keep the language in their head all the time is very low.
There are minefields everywhere.
This is sounding a surprising amount like Javascript at this point. Not hating on JS, but it has significantly changed over the years while maintaining backwards compatibility.Looking at a codebase I can pretty much pinpoint when it was written (± 3 years).
I shudder at the thought of people who onboarded in JS in the last 2 years coming across a 20-year-old codebase though.
- Widely deployed in a variety of contexts (web, embedded, desktop applications, etc.)
- Relatively spartan standard library
- Variety of build setups and toolchains (eg: Make, CMake, Bazel, Babel, gulp, etc.)
- Variety of dialects and trends (eg: classes v/ prototypes, RAII, boost, handlebars.js)
But now... I don't even recognize the language anymore. The syntax looks alien and clunky. I've also gotten used to writing Java and Python with IntelliJ and PyCharm respectively, to the point that writing C++ feels painful now.
I don't like this. I wish I could find the joy of C++ again (I also like high-paying jobs). Any suggestions of books / courses / tutorials to learn modern C++?
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.
Er, maybe people don't want to work for a crypto company. There's the downside potential of going to jail. Like Madoff's programmers.
My home projects are mostly embedded systems things, and for those, I use C++ -- barely. I use it in the old "as a better C" style.
I've also missed the boat now, as I've gained more seniority I'm certainly not dropping in salary and benefits to become a Junior C++ developer and I will probably not be hired for senior functions.
Why would someone burn a sizable chunk of their energy & free time to just entertain those C++ standard committee members sitting on a pile of their RSUs who intentionally delayed almost every single reasonable additions to the language. We are talking about a language that took almost 40 years to get networking support into its standard library! It is a modern museum of bureaucracy in Computer Science.
Some people mentioned the term "modern C++", let's be honest, that is mostly C++11 or C++14, you'd be lucky to get C++17. I won't call 10 years old C++14 modern. Just check where were golang and rust back in 2014 and how much they've changed & created. Modern is the term reserved for languages driven by its user community, like golang, rust, zig etc. New ideas get from open proposals that can be directly commented on by everyone to production in a few quarters, not a few decades.
I mean come on, why would someone with reasonable plan for his/her career choosing to put himself/herself onto that sinking ship called C++?
Let's be clear, learning C++ in 2023 is like migration to Russia/China/Cuba - you give away all your reasonable freedoms & funs to submit yourself to the mercy of a close group of "elites" who try so damn hard to dictate your life & work.
No it is not.
> Let's be clear, learning C++ in 2023 is like migration to Russia/China/Cuba
No it is not.
> you give away all your reasonable freedoms & funs to submit yourself to the mercy of a close group of "elites" who try so damn hard to dictate your life & work.
No you do not. It is not a slavery operation.
Learning C/C++ now is a good foundation as to why things like Rust and Zig are popular. Understanding the underlying mechanics is good. To say it's a major career limiting factor is hyperbole at best.
the same can't be said for C++, e.g. its OO concept seemed to be cool back in the 90s, but after so many decades, at the core of a legacy language, it is now well known that OO is not the choice, modern languages no longer focus on OO for good reasons.
I encourage everyone to learn C, if they have time, learning ASM is also a good investment. At the same time, I think C++ should be depreciated.
Specifically smart pointers that track ownership, raii.
One of the problems C++ has is that this doesn't mean much. In the late 90s when I was an undergrad at college, the main language in the curriculum was C++...
... except it really wasn't. It was a dialect subset of C++ that was what undergrads could wrap their minds around. It was basically C with classes, and even then, the undergrads did a lot of copying and pasting around that whole class thing.
I remember when I was a TA in an early class for the majors, and the central staff updated GCC to a version with namespace support in the middle of one my labs, and suddenly every person in the class had their programs break simultaneously, because this version of GCC had namespace support, and now everybody needed "using std;". Fortunately I could read the resulting error message and worked the problem out in about 10 minutes, but none of the "people learning C++" knew what namespaces were.
I occasionally glance at C++ learning programs the schools are using. They haven't meaningfully changed.
So, a lot of those people "learning C++" really aren't. I expect your average bachelor's degree holder in a programming degree couldn't tell you about move semantics, or explain what exceptions really do in C++, or any number of the sorts of details you need to call yourself a C++ programmer in 2023, let alone a skilled one. C++ is so big.
Also, it's changed a lot. I learned C++ as my first language, but haven't used it nor kept up with it for the past 15 years. I'm pretty sure that idiomatic C++ is just a different language now than the one I learned, despite the name and basic syntax staying the same.
It's telling that:
1. they can whine and get an audience
2. that we tolerate such whining when it is rooted in their feelings of having less leverage in this situation
3. it is spun to be an industry-wide "issue" rather than one that can be solved at an micro-level by using pre-existing incentives of pay.
Simply put, they don't want to, which is why they're in the position of complaining that the world is not to their liking.
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.
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.
> However, only 9.3% of respondents used Rust at all and only 8.8% did so professionally. C++, meanwhile, languished at 48%.
Oh, and don't forget the classic tweet these clickbait bloggers love to quote from official Microsoft Cloud Man, Mark Russinovich......."C++ bad, Rust good".
Last time I looked typical job of Senior C++ dev would pay between £35-45k. Now it seems a little bit better, but still sounds like a pittance.
Maybe they need to up the offers to the region of £300k to get people interested.
New grad packages are usually in the 4XX-5XX range.
I try to keep up with the new standards and incorporate features that I find useful in my code, but the majority of it would probably compile with a C++11 compiler. If I were to suddenly be introduced to a code base written by someone proficient in C++20 with some C++23 features sprinkled in; I would likely require some time to figure out what some of the newer code actually does.
Looking at job postings in my area (flyover state), I seems kind of rare when a job is posted that is primarily looking for someone proficient in C++.
Never use objects with behavior. (Ban OOP.)
Prefer monadic types.
Functions should only take or return moved values or const references. (These form linear types when you need state and ensure immutable values for stateless types.)
Never use a template without a concept.
Prefer the stack and ban mutable memory.
You end up with a functional language which resembles Haskell and competes with C. Not even rust has that level of generality.
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.
I have said this before and I will say it again (until you HR people embed it in their minds): if you cannot find C++ developers, start training people and persuade, let alone motivate them to embrace it, learn it deeply and learn its rough corners.
I have lost counting how many interviews I went through and wasn't the right match for them, but loved my zeal for C++ as they have exclaimed with surprise.
When you get rejected so many times, you say "C++?! why bother anyway?" and you give up and follow a different route, using a different toolset that does not asking for the unimaginable, whatever that is they are looking for, and you get respected for what you can offer to them!
If I had the way to gather all HRs around the globe and ask them all at once what is it they are looking for exactly, it would have saved us all from wasting our time.
The whole situation has gotten way out of hand and needs to end, at last!
Even as someone with C and C++ experience on my resume, I just haven't seen that many jobs I meet the requirements for.
But those domains are usually tied to C++ anyways, games, web browsers, operating systems, etc… are usually written in C++ right?
I’ve noticed that it’s not so bad to get someone proficient in Java or C# or Fortran to pick up C++, so hiring people from those backgrounds helps us fill the C++ developer roles. The python and JS devs: not so much.
Not a job a lot of people want to do, even if it pays well.
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).
But I currently live in a 3rd world country which has no software C++ jobs. And I can't get a foreign C++ job because I don't have C++ experience.
Imagine wanting to leave all your networks, friends, family, and culture; get a lifestyle pay cut and still not get a C++ job. All skilled migrants must get a masters degree or PhD in their destination country just to get their get their CV viewed by an actual person.
[Only half kidding]
When you're looking for devs with a "really high level" of skill, that's at the far end of the knowledge curve where you'll find a smaller number of devs. I'd imagine the same holds true for pretty much every language, not just C++.
Most developers could jump into a 40 year old COBOL codebase and safely make changes. This is probably less true for even a 20 year old C++ codebase. Sure COBOL looks old but its complexity is so much lower.
Similarly, I haven't written COBOL in 25 years but I suspect the language hasn't changed much, unlike C++.
I don't understand why trading companies settled on C++, or why they need a "really high level" of proficiency with it. But it seems like a self-inflicted problem.
Just like I said when this article was originally posted last December, this is totally ignorant of history. Java obliterated C++ in the enterprise space. All of Java's marketshare today would belong to C++ had Java (or any other language of its ilk) never been produced and/or popularized.
There are 'experienced', 'hard working', 'team player', 'junior' (aka cheap)and even 'senior' (a developer's developer) but 'talented'?
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.
But in all honesty. I would rather like a non C++ job, because i have ~30 years of work before me, and i don't want to end up like those dinosaur Cobol or C programmers today.
It's the new COBOL!
So now's the time to learn C++?
You can't just take Joe Blow and send him to a C++ bootcamp and expect him to be useful.
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.
* I have since re-joined
Edit: Oh, and let me stay on the West Coast.
Nowadays, I get paid for PHP and Python, so that's what I do.
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.