Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

541–550 of 869 posts

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

#541
post #510

As someone who has been painfully self-teaching C++ for the last ~1.5 years on and on, these are my hangups: - The features that make C++ decent are often found in C++ 20/23, for which there are woefully few resources - Code taking advantage of coroutines and generators isn't commonplace yet, rare to find examples - C++ 20 concepts are a near mirror copy of Rust Traits and enable composition that's an alternative to…

Interesting that I also am learning c++ since some months and I have a very similar feedback as you. Just to add something: > - C++ 20 concepts are a near mirror copy of Rust Traits and enable composition that's an alternative to inheritance, again difficult to find examples of I don't know Rust, but they remind me of Scala traits. I guess it's conceptually the same, and Scala comes first :) > - The features that mak…

That project options tool is pretty neat, thanks for sharing!

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

#542
post #19
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…

Isn't it common for C++ devs in finance to make seven figure salaries?

Not at all. This is a complete falsehood spread most likely by the financial companies themselves. I worked at Investment Banks for many years, doing low level C/C++ type stuff in various flavors of algorithmic trading and high frequency trading. I left in 2014, because I got an offer for 40% more just doing pure web stuff in Javascript. In the years since I have more than quadrupled my TC, and my neighbor, who is essentially sitting in the seat I sat in when I was working in finance, in that period has upped his comp by maybe 40%.

And on top of that, I rarely log in after hours or on a weekend. In finance, my real breaking point came because there was just an absolute refusal to architect to be able to make changes during market hours, which are essentially 9-6 these days- most securities have a big enough of an extended session that you can't push changes until after. Any significant network changes, host swaps, etc... all had to be done on the weekends. In the web world, you had to bake the ability to make changes on the fly from the very get go, there is no off-time when there is no traffic. And in my last team, we actually avoided pushing changes with any significant risk on Fridays, because if something really bad did happen, it was going to be very hard to get ahold of the right people to diagnose and fix it...

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

#543
post #393
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…

There's also the opposite problem: older devs will use outdated features and have best practices in place that are now considered antipatterns. This exacerbates the existing difficulties to modernize legacy code bases and creates incentives to not do so. New devs are forced to learn C++ from 20 years ago which is much worse than modern C++.

The difference between C++ today, and what we had 20 years ago is not much. C++ has functionality built in today, we didn't have, but the OS provided, and now the language has many features we wished we had years ago.

Example: Variadic templates. When that happened, the problems we would bang our head against the wall with magically vanished. Twenty years ago, every implementation of the std library had serious bugs in it. It was avoided. Not the case today. I remember a std::map iterators not working. Watcom's C++ had serious flaws with it, but many exciting products were still created with it.

We didn't complain. We were happy, and worked around our problems.

I think the root of peoples issue with C++ is with template meta programming portions of it, which you can completely ignore, and grow into.

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

#544
post #535

Earlier quoted context omitted.

> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason). It's quite a bit easier than Rust and no other popular language has its most important features (cross platform, interfaces with syscalls and other libraries easily, manual memory management possible, likely to be supported for a long time).

Having used both C++ and Rust extensively, I would say that it is easier to get something to compile in C++ than in Rust, but I find Rust overall much easier. C++ is really very complex, and even after more than a decade of using it there are so many things I don't know. With Rust I feel like I have a pretty solid grasp of most of the language.

I agree.. I've been writing in Rust for about 2 months and I find it to be a much easier surface than C++.. getting over the borrow checker isn't as bad as some make it out to be.. in fact, if it compiles it largely works.. you might be cloning one too many strings as a newbie, but you get the hang of it quickly.. when I wrote a lot of C++, I used a really small feature set.. but that was like 20 years ago.. now (apparently) it's a lot better.. with Rust, you need to think about memory, stack, and heap, but it's not ridiculous. The type system is really great. Granted, I'm not writing a database, but so far, I see a lot of really good libraries that integrate really easily, and it's just fun to use. The functional features and futures feel a lot like scala... and it's fast.

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

#545
post #510

As someone who has been painfully self-teaching C++ for the last ~1.5 years on and on, these are my hangups: - The features that make C++ decent are often found in C++ 20/23, for which there are woefully few resources - Code taking advantage of coroutines and generators isn't commonplace yet, rare to find examples - C++ 20 concepts are a near mirror copy of Rust Traits and enable composition that's an alternative to…

Interesting that I also am learning c++ since some months and I have a very similar feedback as you. Just to add something: > - C++ 20 concepts are a near mirror copy of Rust Traits and enable composition that's an alternative to inheritance, again difficult to find examples of I don't know Rust, but they remind me of Scala traits. I guess it's conceptually the same, and Scala comes first :) > - The features that mak…

> I don't know Rust, but they remind me of Scala traits. I guess it's conceptually the same

Rust's traits are typeclasses. Scala's traits are like Java interfaces but more.

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

#546

Earlier quoted context omitted.

> No one is paying the implementers of those languages Lol what? Yes they are. I literally work with a whole team of them! Teams at Goole, Apple, Mozilla, etc etc as well.

You understand that it's the ratio and comparative numbers right? A single team of C++ developers creating that stuff can support infinity python programmers building on top

Yeah - but it's not 'no one'.

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

#547

Earlier quoted context omitted.

> You don't need much knowledge to make a circuit board Not quite. For most modern high speed designs PCB's are very far from being simple. Signal and power integrity are critical. It doesn't help that these can be "voodoo" fields where, a bit like RF, years of experience as well as the theoretical foundation are really important. That said, I think I know where you are coming from. A ton of low-performance embedded…

As someone who's not an EE (with no degree in anything at all) and has made many circuit boards... No, they're not that complicated. Not really. I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science.

> I've even designed an analog hall effect keyboard PCB with integrated IR sensor, dual power regulators (to handle 95 ultra bright RGB LEDs), invented-by-me analog hall effect rotary encoders (incremental and absolute), and more. It wasn't rocket science.

Sorry to burst your bubble...

Glad you learned enough to do it and had fun with it.

Yet, such PCB's are trivial to design. Heck, one could auto-route something like that and get a working board for prototyping. In fact, I have done exactly that many times over the last four decades for keyboard/control-panel boards. And auto-routers suck. The fact that one can actually use one for a PCB is a good indicator of how trivial that design might be.

One of the big differences between hobby PCB's and professional EE-driven PCB's is in manufacturing and reliability.

It's one thing to make one or a few of something, anything. Quite another to make hundreds, thousands, tens of thousands, millions. As an example, I am pretty sure you did not run your design through safety, environmental, vibration, susceptibility and emissions testing.

For an example of complex design one can look at such things as almost any dynamic RAM implementation, from SDR to DDRn. Timing, signal integrity and power integrity are a big deal and can make a massive difference in performance and reliability.

Another example is just-about any PCB used in automotive designs. They have to survive brutal power, thermal, vibration and RF environments for decades. This is not trivial.

Other fields with critical needs are medical, aerospace (which includes civilian flight) and industrial.

Consumer electronics is actually quite critical at the limit because you are dealing with very large numbers of units being manufactured. In other words, while a design for something like an industrial CNC machine might only require a few hundred or a few thousands of boards per year, in consumer electronics one can easily be in a situation where we are running 50K to 200K boards per month. Bad designs can literally sink a company.

I understand though. From the frame of reference of a hobbyist or enthusiast everything can look simple. That's pretty much because they just don't have enough knowledge or information. This means they only have access to the most superficial of constraints, which makes PCB's seem easy, maybe even trivial.

As my wife likes to say: A google search is not a substitute for my medical degree.

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

#548
post #245

Earlier quoted context omitted.

> 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 Preach it!

This comment doesn't really align with the HN guidelines.

Neither does yours (or mine).

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

#549
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…

It's amazing how badly embedded programming and C++ programming in general pay compared to the others you mention like Python & Ruby. A good C++ programmer has to know a whole lot more (and be careful about a whole lot more) than a Python or Ruby programmer does. C++ is well known to be a complicated beast - probably the most complicated programming language in existence with plenty of footguns. And an embedded devel…

I've gone from Python to embedded C++ recently and this is my experience, although I would add that C++ devs know a lot more at the lower level of abstraction such as Linux, toolchains, etc which makes them seem like wizards. Outside of embedded, a good Python or NodeJS engineer has opportunities to do more automation and value added activities such as CI/CD, test automation, devops, etc.

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

#550

Earlier quoted context omitted.

I left my last job which was entirely C++ because of lower wages compared to the industry and low upside in wage growth potential. While I enjoy the lower level nature of that kind of work why stay somewhere solving hard C++ problems when I can go do some easier web backend stuff somewhere else making 15% more or become a kubernetes expert and break into new pay band all together?

>solving hard C++ problems when I can go do some easier web backend stuff As guy who worked with both C++ and backend I would assume you don't have much experience if you say one is harder than the other. Different beasts, different problems to solve, complexity lies in different parts.

I did low level C/C++ stuff in the algo trading world until 2014, and since then have done a plethora of other things from node.js for a BIG e-commerce player, python, cloud architecture, SRE type stuff, etc... and every single job has been an absolute cakewalk compared to fighting against the various footguns and headaches C++ has to offer. No more fighting huge object hierarchies and having to put in hacks because making a change to the base class would require half the company to recompile, no more migraines from template compiler errors vomiting out on my screen, debugging template metaprograms, memory leaks, "oh crap this copy constructor doesn't do what I assumed it would do " type errors, "I have to read 10 different files worth of code to track down whether this legacy library is going to delete the object for me or I have to do it myself" headaches, dealing with huge build times, etc... I could go on.

C++ is essentially 4 different languages rolled into one (C, C with classes/OOP, templates, template metaprogramming), and while I am sure greenfield entirely modern C++ projects exist and are a bit nicer to deal with, they are unicorns for most devs out there using the language daily.

Post reply on HN