Live data from Hacker News

The pool of talented C++ developers is running dry

efinancialcareers.com

621–630 of 869 posts

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

#621
post #494

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). And what can be used instead of C++? C? If C was better, then C++ wouldn't have been invented. Rust? It's much more painful to use than C++. Zig? It's immature and has very low usage. Nim? Has very low user base. Julia? It isn't solving the same problems.

Mark Russinovich (of Sysinternals fame), thinks Rust should be the non-GC language of choice moving forward. https://twitter.com/markrussinovich/status/15719951172335042...

I do not think so, though.

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

#622
post #229

Earlier quoted context omitted.

I'm always conflicted with this. My gut says any new student should start with an interpreted language like Python or JS/TypeScript. As that gets you to running code, and core concepts like variables, loops and if statements in little to no time. However, there is value in learning some of the under the hood concepts such as pointers, structs, memory layout, endianess, pass by reference, compilers etc. I don't think…

I have written maybe one binary search that went into production code in 20 years of software development work. It is absolutely an under the hood concept. But knowing how it works so that I can leverage the concept efficiently is super important. Having a sorted or unsorted list/array/tuple/whatever-linear-thing and an functions that search them and then knowing what the performance characteristic will be like and h…

Exactly. And understanding WHY you should prefer using a Struct (or class) instead of a dictionary / hash-map. Can you feel the PAIN of all that additional cost??

The Python / JS world is all dictionaries. Such a developer might never understand why their language runs slower.

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

#623
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++.

My experience with C++ is that every five years I come in and see people claiming that not only should I never do whatever I was told five years ago, but actually it was never popular and nobody ever did it. Mostly about ways to allocate objects or use smart pointers.

I'm still wondering why `(int)` is spelled `reinterpret_cast` in C++. Do they just like hitting keys on the keyboard?

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

#624
post #575

Earlier quoted context omitted.

Banks in general pay a lot less for C++ devs than prop trading firms do.

I should have added that I worked in prop funds during that period as well, I left finance for a bit to do "pure tech" and then went back to a top N hedge fund until recently (and while there are always silly arguments about these things, N was rarely considered greater than 5) for about 5 years, and while yes everyone was paid nicely there, no one was paid 7 figures for their C++ skills. Quant researchers that were…

At my shop, my boss makes 7 figures. Some of the other very senior engineers make those too. At HRT, Jump, it definitely happens more. Jane Street is not a C++ shop, they have devs making 7 figures too.

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

#625
post #465
post #259

Earlier quoted context omitted.

At a previous job, the project lead (mechanical) assigned the embedded team (2 people) writing the firmwares for 3 boards (multi-element heater control, motor controller and move orchestrator with custom BLDC setup, multi-sensor temperature probes) in 2 weeks over christmas, because the junior EE said “I can control a motor with arduino in 30 minutes.” My only guess as to why such a disconnect from reality was possib…

Oh, no, this was super common. When the Arduino (and, soon afterwards, the Pi) were launched, for several years, about 20% of my time was spent explaining higher-ups why there's a very wide gap to cross between a junior's "I can control a motor with Arduino in 30 minutes" and "We can manufacture this and make a profit and you can safely ship it to customers". Don't get me wrong, the Arduino is one of the best things…

Ha. Try telling a customer that even though he's prototyped his machine with three arduinos (he used three because he couldn't figure out how to do multitasking with just a single one...) in a couple of weeks, it will be a $100k project to spin up a custom circuit board and firmware to do the same thing. And no, we can't reuse the code he already wrote.

[sigh]

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

#626
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.

Yes, but when you want to do linked structures, really generic code without repetition or decent compile-time programming, then C++ is very powerful at that.

These things are useful in many situations.

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

#627
post #411

Earlier quoted context omitted.

Java and Python's notions of type safety are completely brain damaged. I can't imagine how things would have gone if I'd learnt them as first languages. Rust, C and C++ get that better, in my opinion (you have to consciously choose to write type safe code in two of those languages, but at least it is possible in all three). Go's thread safety is way behind Rust's. meh.

I would argue C++ type system is superior to even C# and I'm a huge fan of C#. But more to the point, people claim it's somehow harder in C++ to learn programming so either I'm super smart or they're wrong.

The C# standard library is more consistent and powerful (batteries included, more modern). That means there is a "standard, correct" way to do most things in C# in a multi-platform way. C/C++ has massive variety here.

Memory management is trivial in C#.

So yeah, C# is easier to learn. Perhaps you're super smart?

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

#628
post #580

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).

It _looks_ easier because it lets you do anything you want. C++ makes you feel like you're going faster, but then you spend two weeks debugging a weird memory issue. I come from functional programming background, so I'm all for taking a little bit longer to make my code compile if that means it'll work. I'd rather deal with compilation errors than waking up at 2am to debug a stupid segfault.

> but then you spend two weeks debugging a weird memory issue

this is not true anymore 90% of the time if you code with a decent knowledge... if you code C, then yes.

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

#629

Earlier quoted context omitted.

Yes, the embedded space pays terrible, and the employers don't seem great on the whole. When I was at Google I got to work on embedded stuff and really liked it; but I was getting a Google salary. When I left Google I pursued IoT and embedded jobs a bit and while I was not expecting Google level compensation at all, I was astounded at what was going on there, pay wise. General software eng back end jobs pay better. T…

Isn't this a sign of a problem ? where important domains with hard problems pay few .. while some dubious applications are throwing money on css plumbers ?

No, it's always been the case. Just because something is difficult, doesn't mean it pays well. Otherwise, teachers and mathematicians would all be millionaires.

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

#630
post #60
post #27

Earlier quoted context omitted.

Having recently learned C++/C.. I don't see why it would be taught as a first language outside of specializations. The gains from C/C++ coding are vastly outweighed by the costs. The reality is that there is no good, agreed upon standard in C++ for how to manage memory... how would you teach this to junior engineers at university?

But there is! Use local variables and value semantics. Use references to borrow stuff. Never touch new or delete. Use smart pointers when need an owning pointer (rare). Anything beyond that: ask next in seniority to supervise. That should be enough to live a happy C++ life for a junior.

Ah, I think the parent was referring to C++ circa 1990 to 2010 - prior to the much more happy modern world with standard smart pointers.
Post reply on HN