Andy Kelley noted that contributions to the self hosted zig compiler were way higher than to the C++ one. This matches up with my experience. I’d love to work on Swift but do I want to work on it so much that I’d write C++? Nah. Ditto PyTorch, XLA, LLVM, etc. I should probably bite the bullet and learn C++, but dammit Rust land is so nice.
The pool of talented C++ developers is running dry
271–280 of 869 posts
Re: The pool of talented C++ developers is running dry
#272I've been C++ the majority of my career, doing simply amazing shit... and a recent recruiter did not recognize anything I was discussing and asked if I even wrote code. I worked on the original PSX OS, I've delivered over 40 commercial products, all written in C++ and that meant nothing.
I get this too. I wrote a number of design/game engines, design applications, and frameworks in C++ and I get recruiters that don’t understand that and start asking me basic C++ questions. One time they were reaching out to me about a design engine I wrote and didn’t even realize.
Indeed they will end up asking you little questions that have zero to do with your engine and ding you for not knowing some particular trick. It drives me crazy.
Re: The pool of talented C++ developers is running dry
#273Is the pool running dry or are they simply not putting enough water in or allowing enough people through the gate? I've seen the job ads. Must have five years. Must have x, y, z. For a junior position. Unrealistic.
Same person can get a web job elsewhere with much less nonsense. So off they go.
Like a lot of things in IT these shortages are nonsense. They are lobbying for visa relaxation or similar so they can pay less.
Re: The pool of talented C++ developers is running dry
#274Earlier 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…
> 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.
Re: The pool of talented C++ developers is running dry
#275Because 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…
> Employees may be leaving the embedded space Embedded opportunities have been slowly shrinking for years. For whatever combination of reasons, a lot of employers think that embedded work is easy or otherwise doesn’t require a large budget. It’s increasingly bizarre to get a well-designed IoT device with a very polished mobile app and web UI, then struggle with hardware factory resets and firmware upgrades because th…
One thing I came to see working in both web and embedded for two decades now: a lot of embedded developers often miss the “product” side of what they are building. This probably doesn’t explain the lower pay, but it might be a reason why embedded overall doesn’t get the recognition it deserves: the embedded engineers don’t know how to communicate their value / provide more value to the business.
This is becoming increasingly important as you well note, where devices are all connected, and things like setup and updating and connectivity are crucial. Designing not only a robust, but a user-friendly firmware update process is actually a lot more work than just building a bootloader: you need to communicate to the user, in realtime, what is going on. Cancelling an action needs to be immediate and provide feedback on the process of the cancelling. Error handling needs to provide useful information, and probably a special UX.
These do need to be factored into the embedded software right from the start, because they significantly increase the complexity, and it’s extremely easy for management to miss how crucial that part is. I keep a few horrible chinese consumer electronics devices on hand (webcam, mp3 player, mobile phone) to show what I mean. The only difference between an ipod touch and a noname mp3 player with touchscreen is… the software.
Having to press 3 inaccessible buttons, connect a USB volume named “NO NAME”, have it hang for 2 minutes when unmounting, then show a black screen for 3 more minutes, before showing … that it didn’t update, vs a smoothly progressing update progress bar showing the steps, the devices showing up in my online dashboard as soon as it reboots, that’s what my value as an embedded engineer is.
Re: The pool of talented C++ developers is running dry
#276>The real problem is that C++ is neither easy nor loved. Rust got an 87% approval rate in the "most loved" category of the Stack Overflow Survey. However, only 9.3% of respondents used Rust at all and only 8.8% did so professionally. C++, meanwhile, languished at 48%.
It seems that developers who never used Rust love Rust. I love neither but if I would to pick one to use, I would pick C++ because for myself is much easier.
Re: The pool of talented C++ developers is running dry
#277Earlier quoted context omitted.
I am no expert, but I am under the impression for HFT that high performance is the absolute goal and slight percentages in performance can affect profits.
HFT entails only a small part of the usage of C++. It's still being used in many embedded systems (including automotive, aviation and building automation), where Rust is also available. Interop is always possible with C/C++ so there's little excuse not to use Rust there.
I was only addressing HFT as that was where the pleading by the author for more devs is coming from.
Re: The pool of talented C++ developers is running dry
#278Earlier quoted context omitted.
> Because Python pays more. Or Javascript. Or Ruby. But these are all implemented in C++ or C? Those aren't low-paying jobs.
But most implementors are hired by Big Techs, which means you have to be really good to get a decent job with C++. In the meantime, JavaScript and Python is a lot easier to work with, with a higher salary.
> In the meantime, JavaScript and Python is a lot easier to work with, with a higher salary.
I don't know - I legitimately think programming languages are simpler than web applications. Mostly stateless, mostly a big pure function. Compared to the anarchy and chaos of web services seems easy.
Re: The pool of talented C++ developers is running dry
#279Earlier quoted context omitted.
The style guide is publicly available: https://google.github.io/styleguide/cppguide.html I've never heard anything remotely similar to "avoid objects" here.
Well, this was back in the C++ 11 days. No biggie. Won't get in a fight about it. Have a great day!
It is true that the adoption C++11 was later than ideal. Since then, the C++ build and library maintainers have made a priority of not letting that happen again and have done a really really good job (IMO).
Re: The pool of talented C++ developers is running dry
#280Earlier quoted context omitted.
Perhaps in the past, but they aren't too terribly far behind C++20 and a bunch of stuff that has been added to the language over time (like stringviews) was made available much earlier via library support. I don't think I've ever heard this "C+-" joke at Google despite working in C++ here for a very long time.
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.