Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

341–350 of 869 posts

Re: The pool of talented C++ developers is running dry

#341

Earlier quoted context omitted.

> But these are all implemented in C++ or C? Mostly, but Rust is increasingly replacing them.

Which of those languages are being rewritten in Rust?

I meant that increasing amount of projects related to Python/JS and others that would previously be created in C/C++ is now created in Rust. Some examples:

TypeScript type checker written in Rust Ruff – a fast Python Linter written in Rust Introducing Turbopack: Rust-based successor to Webpack Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust.

Re: The pool of talented C++ developers is running dry

#342
post #64

Earlier quoted context omitted.

> All of this to say: if you want C++ programmers, you need to pay competitive enough rates to pull them away from there. I'd modify this to say "All of this to say: if you want programmers, you need to pay competitive rates." I worked in real estate for a while (as a software dev) and my boss, who was a realtor, always said "there's no house problem that price can't solve". The labor analogy for me is "there's no la…

Although the pound has recently crashed, the general rule for comparing UK salaries to US ones is to 1.5x it to dollars. A £150k salary in London is equiv to a ~$200-250k salary in the US. Not bad, I'd say.

While it's of course good by local UK standards, I still think sometimes London needs to recalibrate to pay closer to US norms. Cost of living in London is often just as bad as major US coastal cities. At my work, they recently introduced a London office paying eng roles in similar salary range, and lots of opportunities to move there with help provided for relocation fees. For many the interest evaporates when they see typical dev pay package and CoL in London.

Re: The pool of talented C++ developers is running dry

#343
post #9

Because Python pays more. Or Javascript. Or Ruby. More demand, more salary. Apart from finance, pay is lower than web languages. And finance is small. Embedded systems programming, that also uses the language, pays 30% less than web jobs from my last job hunting period. Employees may be leaving the embedded space (and C++) for web tech because of this. This is the feeling I get from my local job market (western Europ…

Said finance companies are also at fault. They are not willing to scale up their operations. They demand only the creme de la creme, but there’s simply not enough incentive to do C++ when the compensation is so bimodal.

Re: The pool of talented C++ developers is running dry

#344
post #25

Rust should make the pool of C++ developers decrease exponentially in the coming decades. There's little reason to code a greenfield project in C++ unless it involves leveraging some niche libraries, and those niche libraries will eventually have Rust equivalents.

C++ doesn’t require you attend an annual furry convention.

Annual furry convention might be fun though wdym

Re: The pool of talented C++ developers is running dry

#345
post #312
post #9

Because Python pays more. Or Javascript. Or Ruby. More demand, more salary. Apart from finance, pay is lower than web languages. And finance is small. Embedded systems programming, that also uses the language, pays 30% less than web jobs from my last job hunting period. Employees may be leaving the embedded space (and C++) for web tech because of this. This is the feeling I get from my local job market (western Europ…

I've wondered why embedded tends to pay lower. C++ (and C) tend to be 'harder' languages for the average mainstream developer, particularly web developers. I guess I expect embedded jobs to pay more, yet they don't and like you said, pay less. But why is that?

In embedded you sell hardware, with web you sell software. Software scales a lot more than hardware, thus more revenues per employee.

Re: The pool of talented C++ developers is running dry

#346
post #127

Earlier quoted context omitted.

I did a few a few months of contracting at a major voting machine company. They make a significant portion of all US voting machines. They had 4 developer teams Firmware (C++ where I was), UI (web tech on a voting machine), poll book (java), and a web/support team. Before I was hired in a massive influx of contractors each team was something like 3~5 people, except UI which was a new team with the contractor hiring s…

Sounds… problematic. What can you say about the state of security with it?

The code is quite secure, but the process and company are... typical processes and company people. Paper ballots and physical boxes are more secure if good practices are followed.

At one point I was tasked with shuffling the data layout on disk in real time to mitigate de-anonymization attacks. Security was real concern.

Crypto everywhere. The voted ballots were encrypted with keys generated and delivered immediately before the election. No networking by default. The end product had all the right things.

That said, no one had clearances, third party auditors were morons, and pay wasn't great. So if I were an attacker I would just try to bribe people to make the changes I want. Can't bribe a ballot box company to election tamper, because they just make boxes.

With all that effort they are still needless voting machines, they each count a few thousand votes and not all produce a physical paper trail. Because they have software and logic in them they need a constant chain of custody to make sure that the code we wrote is what is actually run.

Just use a box and paper, it is safer all the ways digital things suck. A precinct counting votes only needs to tally a few thousand ballots so it might take a team of people a hour or two, less time than to fix a potential technical problem.

And paper can more easily have bipartisan oversight and can have physical security measures that are impractical on a computer.

All that said I have no reason to believe our elections have been tampered with on a national level or that anyone other than a local republican may have used our machines to steal elections, even then no firm or even circumstantial evidence, just baseless suspicions and conspiracy theory level anomalies.

Re: The pool of talented C++ developers is running dry

#347

Earlier quoted context omitted.

> The labor analogy for me is "there's no labor shortage that salary can't solve". Perhaps not in SW, but there are plenty of labor shortages that salary can't solve. Some positions are simply not economically viable in certain markets - the pay required to get people to do them is more than a given business can afford. And I don't mean in the "cutting into the compensation of the business owner" type, but "not enoug…

> labor shortages that salary can't solve. Some positions are simply not economically viable in certain markets Your two sentences are opposite of each other? If someone can't afford to pay employees market rate, they need to rethink viability of the business not say that they can't find someone.

> If someone can't afford to pay employees market rate, they need to rethink viability of the business not say that they can't find someone.

Your statement is pretty much what I'm saying, with the added "in certain markets" clause. That a market can't support such jobs doesn't preclude it from being a labor shortage.

Think of it this way: A given business has a certain job that was economically viable, and they could find the labor to do it. Then over a few years the economy changes significantly (feds raise rates, cost of living changes, etc), and slowly that job no longer is viable in that market. The change will not be sudden, so there will be a period of a few years where businesses still find people to do the work, but the pool of such employees keeps shrinking before it hits zero. It's fair to call that a labor shortage in the transition period.

Re: The pool of talented C++ developers is running dry

#348

Earlier quoted context omitted.

I heard it quite frequently, but not from people that worked there. I believe that there was a published style guide. My experience is years old, but I remember seeing that it was basically “C++ without objects.” It’s a great language, and the 20 additions bring it right on par with other languages, in terms of type and memory safety.

Maybe more like C++ without (most) pointers. A coupe of years ago they allowed mutable references in function arguments, so the use cases for passing pointers around were reduced even further.

That's it. Not "without objects," but without pointers. One of the things (back then) that made C++ so powerful, was direct memory access.

However, I really like style guides.

Except the Taligent one: https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoo...

Re: The pool of talented C++ developers is running dry

#349
post #209

I’ll offer a perspective unrelated to pay: It’s a pain to start learning C++, and even after you do, older devs will roast the hell out of your code because your book/tutorials of choice forgot to mention a crucial (in their opinion) feature that you absolutely should/shouldn’t use! Not to mention you’ve only programmed on Mac/Linux so far & windows is totally different, has a different compiler, different ways to in…

This. Learning the language as a whole is an incredibly daunting task. It's ugly, it's built on a combination of OOP and procedural C and quite frankly, the class syntax in combination with header files has aged pretty bad. I feel like I have a lot of code I need to write twice. The standard committee keeps tacking on new features and decade old footguns are promised to never be fixed (and somehow, people consider th…

It's only ugly because it was meant to be a federation of different programming paradigms. You can mix low level C calls with homegrown RAII frameworks, or mix traditional OOP with functional programming. Once you start throwing in preprocessor macros, meta programming, and templates, you can have a codebase that is incredibly complex to understand and maintain.

As for the header/implementation separation, I always thought it was a good idea to have that flexibility. I've worked in codebases where the compilation units were fairly large and complex and would be implemented in separate files. This would be similar to partials in C# I've also worked with some code that would determine the target compilation units at build time. Not saying it was the best approach at the time, but it was one option.

If anything scares off people from C++, it would definitely be the breadth of the language, though. You could work in C++ for over ten years and possibly not even encounter or use half of the functionality it provides. And because of it's breadth, going from one C++ codebase to another could look completely different. Especially when looking at something written for a Unix/Linux/Posix system vs Windows.

Re: The pool of talented C++ developers is running dry

#350
post #127

Earlier quoted context omitted.

I did a few a few months of contracting at a major voting machine company. They make a significant portion of all US voting machines. They had 4 developer teams Firmware (C++ where I was), UI (web tech on a voting machine), poll book (java), and a web/support team. Before I was hired in a massive influx of contractors each team was something like 3~5 people, except UI which was a new team with the contractor hiring s…

> They make a significant portion of all US voting machines. > Just quadrupled their staff to make a voting machine then fired them all. Fascinating.

Just another project manager trying to hire enough people to make the project happen on time. I am in another one of those situation right now. Nothing to do with anything sensitive, just a team of 9 mothers trying to make a baby in 1 month.
Post reply on HN