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…
The pool of talented C++ developers is running dry
541–550 of 869 posts
Re: The pool of talented C++ developers is running dry
#542Because 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?
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
#543I’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++.
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
#544Earlier 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.
Re: The pool of talented C++ developers is running dry
#545As 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…
Rust's traits are typeclasses. Scala's traits are like Java interfaces but more.
Re: The pool of talented C++ developers is running dry
#546Earlier 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
Re: The pool of talented C++ developers is running dry
#547Earlier 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.
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
#548Earlier 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.
Re: The pool of talented C++ developers is running dry
#549Because 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…
Re: The pool of talented C++ developers is running dry
#550Earlier 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.
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.