[HN Gopher] The pool of talented C++ developers is running dry
___________________________________________________________________
The pool of talented C++ developers is running dry
Author : pjmlp
Score : 332 points
Date : 2022-11-02 14:23 UTC (8 hours ago)
(HTM) web link (www.efinancialcareers.com)
(TXT) w3m dump (www.efinancialcareers.com)
| rock_artist wrote:
| I really don't get this language thing. I do understand that
| having experience with a language is important as any developer
| trying out a new language has a learning curve between months to
| years depends of the needed scope.
|
| There are also "cpp lawyers" that you'll see in cpp conventions
| and are really "part" of the language.
|
| But...
|
| From my knowledge of the ones I admire as software engineers.
| It's not the language. It can be Haskell, cpp, python. I doesn't
| matter.
|
| A real engineer should understand at least basic concepts of how
| a CPU works, memory concepts including manual alloc/dealloc. So
| languge is a fraction of your time.
|
| I've "learned" Java in my university and did a C course. I've
| started without knowing any C++. But since working at my current
| place, I write only CPP.
|
| There's infinite learning curve but that's with any language (or
| knowledge in any field)
| harimau777 wrote:
| Personally, I'm currently transitioning from functional
| oriented JavaScript to Object Oriented PHP and I'm struggling a
| lot with the different paradigm. It feels like everything
| happens by magic rather than according to the neatly organized
| assembly lines that I'm used to.
| pyb wrote:
| Yes ! FAANG hire thousands of developers to write C++, even
| though their tech interviews are language-agnostic.
| praptak wrote:
| "Not enough talent" means "not enough talent for your shitty pay
| and/or horrible work conditions".
|
| I spent my first ~5 years at Google working in C++. Google didn't
| seem to have a problem finding enough C++ folks whose C++ skill
| is basically "writes compilers and maintains a template library
| as a hobby" or "can explain a garbled stack trace in a crash
| dump". Also folks without prior C++ experience did reach this
| level while working there.
| adam_arthur wrote:
| Then start projects in more modern languages that people actually
| want to work on
| btilly wrote:
| I've seen this story several times.
|
| Once a language no longer has a developer pipeline, it becomes a
| language with no future. No matter how important and widely used.
| You wind up with jobs begging for qualified developers. Given how
| systems last, the language may survive indefinitely. As nobody
| dares migrate projects off of it. But employers will struggle
| more and more to find employees.
|
| The first language that this happened to was COBOL. There are
| still a lot of COBOL systems out there. And a lot of COBOL jobs.
| But nobody wants to go into COBOL for fairly obvious reasons.
| gigel82 wrote:
| C++ is not going anywhere. All operating systems and almost all
| compilers for every other language (plus many of their
| runtimes) are written in it.
|
| <s>When the heat death of the universe is upon us and all other
| languages have ceased to exist and re-emerged thousands of
| times over, C++ will still be here, driving the lower-most
| layers on top of hardware.</s>
| btilly wrote:
| I declare your comment to be high quality BS.
|
| First of all I never said C++ was going anywhere. I compared
| it to COBOL which is still estimated to be involved something
| on the order of 60-80% of financial transactions. C++ has a
| similarly bright future.
|
| But secondly, your claim is wildly overstated. C++ is a lot
| less fundamental and essential than you think.
|
| Operating systems:
|
| Linux and the *BSD family are written in C, with Rust making
| some headway. (But C++ would be over Torvalds' dead body -
| see http://harmful.cat-v.org/software/c++/linus for example.)
| OS X is written in a combination of C and Objective C.
| Android is written in C and Java. Windows has a lot of C++,
| but the kernel is straight C for reasons that Raymond Chen
| explains at https://learn.microsoft.com/en-us/shows/one-dev-
| minute/one-d....
|
| Not only are not all operating systems written in C++, but
| most of the most successful ones aren't. And multiple groups,
| INCLUDING ones otherwise sympathetic to C++, have concluded
| that C++ is a terrible choice for kernels that are close to
| the hardware.
|
| Compilers.
|
| Well GCC is written in C. (Though Clang is C++.) So are the
| interpreters for Python, Ruby, Perl, and PHP. One of the
| backends for Go was originally C but has been ported to Go.
| (They maintain another C++ backend.) Julia's backend is
| mostly C. (A few libraries are C++.) However JavaScript and
| Java are both written in C++.
|
| Reality is a long, long ways from your claim that almost all
| compilers for every other language are written in C++. In
| fact straight C is a more popular choice.
|
| You didn't talk about GUI applications. But there you'd have
| more of a point - C++ is far more popular there. However even
| that it isn't a slam dunk. Rust was explicitly developed as a
| response to the fact that C++ makes security very hard. The
| idea being that it would be easier for Mozilla to port
| security critical modules from C++ to Rust than to secure
| C++. Since security is getting ever more important, it now
| makes sense to write in a different language first.
| 6yyyyyy wrote:
| >All operating systems
|
| C != C++
| [deleted]
| fouronnes3 wrote:
| If you're an experienced C++ developer today, is it a wise
| career choice to go the "C++ expert" route, or should you pivot
| to something else?
| btilly wrote:
| It depends how much you like working with legacy code, and
| how much you love C++.
|
| If you stay the "C++ expert" route you will always have a
| job, but it will be every more gnarly legacy code. Because
| those who had relatively good legacy code are also those who
| are going to find it easiest to migrate off of it.
|
| Judging by what happened in Perl (the example that I know
| best), I'm guessing that most developers will leave C++.
| Mostly for languages in a similar space. A lot will go to
| Rust.
| dureuill wrote:
| C++ jobs are not going anywhere, quite the contrary. A lot of
| systems won't be rewritten. Besides, at least at the moment
| "C++ expert" is a perfect background for becoming a Rust
| expert should the want arise.
|
| Rust *is* much more enjoyable to program in than C++, though
| jollyllama wrote:
| Depends on your opinion of Rust and the associated community.
| Bost wrote:
| > But nobody wants to go into COBOL for fairly obvious reasons.
|
| On YouTube, type in "COBOL Mainframe", and you'll find out
| pretty quickly that there's a plenty of guys from India,
| including juniors who work with or on COBOL and Mainframes.
| btilly wrote:
| You have a point.
|
| However I'd also say that I'm not surprised to see people
| from India taking jobs that most developers don't want.
| dreadedfuture wrote:
| I can see why since I am searching for jobs:
|
| 1. Juniors are no hired for C++ type roles. Employers want
| someone with 5+ years of experience, because just knowing the
| syntax is not enough. And training on the job is also not
| offered.
|
| 2. It pays shit in comparison.
|
| 3. Job positions are relatively scarce.
|
| My actual niche is numerics (so writing numerical libraries and
| simulations), btw. I was really dismayed to see how shit the pay
| is.
| dvzk wrote:
| #1 needs to be emphasized.
|
| 8-12 years ago I knew modern C++ inside-and-out. I worked on
| high-performance template developer libraries. These days
| whenever a C++ opening comes up in my job feed, it's in game
| development or it requires extensive domain-specific
| embedded/firmware experience. I just shrug and move on.
| sunjester wrote:
| I personally know c++ and know others who are also well versed in
| c++. I have a disagreement with the computer industry and won't
| work in an embedded space. Others won't be hired because of their
| lifestyle, looks, or past record. The pool isn't running dry it's
| being drained.
| sigi64 wrote:
| I was a C++ programmer for 25 years. Last 3 years, I'm using Rust
| language in my daily job and for all my hobby projects. I will
| not return to work in C++ again. No money can make me to change
| my decision. Nowadays, programming is a pure joy for me again.
| This was not the case when I had to work with C++.
| j-krieger wrote:
| I agree. No matter gray beards bashing Rust on HN every time it
| comes up, programming in Rust brings me joy and I will never
| use C++ again if I have a choice.
| gigel82 wrote:
| Interesting; could this be because you've been using outdated
| C++ ? (legacy codebases started before C++98 tend to be
| particularly painful)
|
| FWIW, I prefer the power of C++ over Rust's hand-holding; but
| can also see its appeal for someone that's not as confident
| over the minutia.
| hedora wrote:
| Not the person you asked, but for me (coming from C++20,
| with lambdas, async, etc), the big win is that the borrow
| checker automates away boring PR comments about "you used
| std::unique_ptr in a non-idiomatic way that is technically
| safe, and it bleeds memory unsafety into some random API,
| so write this level N+1 magic instead".
|
| It also checks that all my threaded code is data race free.
|
| On the downside, it's support for safe (in the sense that
| the compiler checks it) lock free programming is basically
| non-existent, which means that stuff that would be easy in
| C++ ends up being in Rust unsafe blocks that you need a PhD
| in type theory to reason about.
| gavinray wrote:
| > On the downside, it's support for safe (in the sense
| that the compiler checks it) lock free programming is
| basically non-existent, which means that stuff that would
| be easy in C++ ends up being in Rust unsafe blocks that
| you need a PhD in type theory to reason about.
|
| I'm not familiar with the C++ built-in facilities for
| lock-free stuff (but learning about them currently)
|
| Could you expand on this if you're willing, maybe with
| some pseudocode?
|
| I've also been curious about things like cache alignment,
| aligned memory, and false-sharing size detection in Rust
| -- all of which C++ has as std built-ins
| zozbot234 wrote:
| Rust has atomic types that rely on interior mutability.
| No unsafe blocks are needed for those.
| returningfory2 wrote:
| > ... but can also see its appeal for someone that's not as
| confident over the minutia.
|
| I think this is mischaracterization of why people choose
| Rust (and FWIW it comes across as condescending). People
| choose Rust over C++ partially for the same reason people
| write unit tests. We accept that no matter how good we are
| at writing software, we are still fallible, and so we
| introduce structures around our work to minimize the
| fallout from that fallibility.
| zabzonk wrote:
| i will admit to the beard, but isn't it strange that the
| number of posts praising rust and haskell has dropped of a
| cliff here in the past months?
| kibwen wrote:
| There are just as many written-in-Rust posts as ever,
| although the practice of appending "in Rust" to the title
| has fallen off (there's literally one of these at #3 on the
| front page right now). Meanwhile, an article from IEEE
| evangelizing Haskell was literally on the front page this
| morning with 256 votes.
| primeblue wrote:
| martin1975 wrote:
| same here. I've pounded C++ and C code for 20+ years. Rust is
| the right tool to replace both of these. Long live Richie (well
| maybe not him but his work), Kernighan and Stroustrup.
| keithnz wrote:
| long time C++ programmer here too, 30ish years, but I don't use
| it for much anymore. While I like that the language has
| improved, it's just a nicer experience coding in other
| languages.
| npigrounet wrote:
| thrwyoilarticle wrote:
| I've drank C++'s kool aid. I believe in the vision and think of
| everything in C++ terms.
|
| ...I think I could last about 3 months in another language
| before I'd forgotten too much to go back.
| gridspy wrote:
| I doubt that's true. I haven't used C++ for many years now. I
| was in your boat a few years ago (C/C++ since 1990) but now
| 6+ years Python then Rust centric. I still think in C++ terms
| when writing rust, although most of the time it's "I would
| need 10 lines to do this 1 line of rust code were I still
| using C++."
|
| I dabble in C++ occasionally as a contractor. No problem
| picking up the new features and making useful contributions.
|
| C++ maps pretty directly into Rust. I found it useful to
| understand the underlying data representation in memory. For
| instance https://doc.rust-lang.org/nomicon/repr-rust.html
| jmnicolas wrote:
| Unless proved otherwise I always assumes that when employers say
| there's a shortage of any skilled labour they just mean they
| can't find someone cheap enough.
| deathanatos wrote:
| Exactly this. I know C++; I'm not using that knowledge. So,
| there's at _least_ me in the talent pool. And my inbox
| continues to indicate that recruiters are anything _but_
| serious about hiring.
| cdelsolar wrote:
| i hate C++ but i can program in it fine enough probably, as long
| as there's not too much template nonsense.
| matthews2 wrote:
| The template nonsense is what makes it fun!
| zeroonetwothree wrote:
| I love C++ and I have 15+ years of experience. But I have no
| desire to work in finance. Apart from that there don't seem to be
| many good job opportunities. So instead I'm slinging JS like
| everyone else and making 500k...
| sgt wrote:
| C++ is the new COBOL.
| DeathArrow wrote:
| >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.
| ptero wrote:
| There are now more options for many tasks that used to land
| squarely into the C++ land: rust for low level and low latency
| stuff; python for a high level glue for some latest algorithms;
| ruby, JS for web.
|
| On the other hand, C++ grew into a very complex language. For
| example if someone is not well versed in template metaprogramming
| meaningfully contributing to an existing project leveraging it
| could take a while.
|
| So when a new project starts, C++ is rarely the top choice. And
| as the job pool shrinks, developer pool does, too; usually even
| faster, as younger developers do not want to be known as experts
| in a complicated legacy language. My 2c.
| kaizendad wrote:
| This is good, right? There are better languages for most
| (although certainly not all) purposes, whether you measure
| "better" through features like memory-safety or through developer
| happiness or anything in between.
|
| Most of the systems that were written in C++ in the past didn't
| have to be written in C++. Now they'll become hard to support,
| because they are in fact hard to support, and eventually they
| will be refactored or rewritten.
|
| Same thing happened with Assembly and COBOL programs being
| written into C++.
| jleahy wrote:
| Unfortunately high frequency trading is an area where C++ is
| normally the right choice, even for a new project.
| varajelle wrote:
| Why not rust?
| jleahy wrote:
| Try doing (serious) high frequency trading in rust, then
| come back to me.
| tdiff wrote:
| Many people here compare c++ jobs to, say, js jobs mentioning
| that the latter are easier and at the same time pay more. I
| wonder if all them really dont care what they do as long as the
| wage is large enough.
|
| I tend to think that in many cases one would deal with something
| more interesting/involving while working on a cpp project than on
| a python web app.
| magicloop wrote:
| The article focuses on the financial world. Historically in the
| UK (and elsewhere) finance roles have had strong interest for
| applicants, and high salaries were on offer. So the industry
| could pick the "most talented".
|
| Now the model has broken down which is the motivation for the
| article. That's because the "talented" C++ developers have been
| hived off by the big tech firms (which can pay equivalent
| salaries or more), or the top video game companies (which
| generally pay low but make up for it in fun).
|
| What remains are the "normal" developers. But their nature of
| business means you can't achieve a market edge with that level of
| talent, all else being equal.
|
| This was never the case for COBOL because that was deployed to
| keep the business running, not for creating unique value and
| market edge. So "normal" developers work out just fine.
|
| Finance firms hire a lot of talented graduates. They need to work
| against their natural inclinations, and provide training and
| mentorship to get those folks up to speed with C++; a long
| journey. They don't want to do it due to being seen as providing
| a cross-subsidy to their competitors when the graduates switch
| companies.
| glonq wrote:
| I wrote in C++ for a good chunk of my programming career. I'm a
| manager/architect now, but if you forced me back into programming
| I'd much rather use C# or Rust than C++ again.
| bjornsing wrote:
| I'd say the pool of talented people in general is running dry.
| fxtentacle wrote:
| No, they're just cheapskates!
|
| I remember this exact same recruiting agency spammed me a $120k
| offer to become Lead Developer for a new quantitive trading
| algorithm. For that salary, they also expected me to relocate to
| London. Some C++ consulting gigs pay $2k per day, so their offer
| just seemed really cheap in comparison.
| MattPalmer1086 wrote:
| I had the most fun ever writing c++ 20 years ago. The power of
| the language amazed me, combining high level constructs with low
| level control and many, many (too many) powerful features. And so
| many ways to completely screw yourself up.
|
| I vowed never to use it again. I miss it still but it's just not
| worth it.
| shadowgovt wrote:
| As the COBOL pool did before it.
|
| C++ was great in its era but has been supplanted by other
| languages for safety and performance reasons and it's fine that
| it's on its way out.
|
| The tail will be long (there are billions of lines of C++ code
| that will need to be replaced or rendered so fundamental that
| they cannot be mutated without breaking expectations), but
| there's no shame in a language running its course.
| jbluepolarbear wrote:
| The main issue for me is pay. I've used C++ for 15 years, written
| many design/game engines, frameworks, etc, but C++ jobs don't pay
| well. In recent years I've been using C# with Unity and I make
| 25-30% more than I would working in C++. C++ has also changed a
| lot over the last 5-10 years (a lot for the worse) and requires a
| big commitment to stay an expert. In order for me to go back to
| C++ full time I'd need a substantial salary increase and a
| project that I want to work on.
| p0nce wrote:
| The problem of C++ is that it's a bad personal investment since
| you will need to re-learn the language all the time. Almost every
| other language respects your time more. Not getting back... ever.
| lpapez wrote:
| Not just the language, entire toolchain and community are like
| this. Yesterday I upgraded my Go compiler, everything worked
| straight away, got free performance improvement on my code. I
| still shudder when I remember upgrading to a new version of
| GCC, Clang, MSVC. Took weeks to setup everything and fix newly
| created bugs. Not getting back... ever.
| Kukumber wrote:
| the west repeated the same mistakes as when they decided to let
| china become the factory of the world
|
| now they pay the price
|
| they thought they could outsource embedded/system devs too, if
| you go check in Indonesia and Taiwan, the amount of people who
| dab with embedded/robotic stuff is insane
| _jezell_ wrote:
| WASM will bring back a lot of the web devs to native, but C++ via
| ecmascripten sucks balls compared to the alternatives.
| dysoco wrote:
| I'd love to get into low level programming, game development or
| somewhere where C++ has to be used (I'd rather use another
| language probably but not gonna get picky); however, in my
| experience (and this might differ vastly since I'm in South
| America):
|
| 1. There are really few jobs doing this here compared to web
| development; there are maybe less than ten new openings in
| LinkedIn a month.
|
| 2. Most if not all of these ask for Sr positions with +5 years of
| experience, there are no jr jobs to get this experience from
| (except maybe from university or public research entities, which
| just don't pay enough to cover rent).
|
| 3. Most of these are just maintaining old legacy software written
| in C++, the jobs in games, embedded, low-latency, etc. are REALLY
| far and between or nonexistent.
|
| 4. Many don't allow for remote work, whereas in web development
| it's the norm.
|
| 5. You can say goodbye to part-time work, it's not the norm in
| web development either, but since there are so many jobs there
| you eventually will find one that'll allow you to work less
| hours.
|
| 6. Even if you get the perfect job, it might still pay less than
| a Sr React position or whatever; I'd personally rather work in
| something interesting for myself, but someone with a family might
| not.
|
| I haven't been investing time in looking for remote work in the
| US or EU yet, in my little experience, they usually do not allow
| for remote work, or only for Sr positions. However I'm sure it's
| possible since there are much more openings outside.
|
| So personally I believe there's a lot for these companies to
| improve so this pool of talents grow, and it doesn't even imply
| higher wages; they can focus on hiring from another countries
| and/or more jr candidates. There won't be more "talented C++
| developers" if these people can't learn or grown anywhere.
| There's a lot of talented people right out of college they just
| don't have the work experience yet.
| TheLoafOfBread wrote:
| I was contemplating to work with C++, but coincidentally I got
| into C (microcontrollers) and C#/.NET (desktop apps). And every
| time when I am forced to work with C++ (.NET CLR DLL libraries) I
| am reminded about general typing overhead which I do not need to
| do in C# - i.e. HPP file with declarations and CPP file with
| definitions; Enums can't be translated to its string
| representation directly, but you need to have some helping
| function to do that... gross.
| fluoridation wrote:
| It depends on what you do. There are things that can be very
| easily done in C++ with a macro or a template that are simply
| impossible in C# and you just end up hammering out brain-dead
| code.
| VLM wrote:
| The article very specifically states "very high levels"
|
| That has two effects:
|
| 1) Given how ineffective the hiring process is at selecting
| skill, they would never hire even Bjarne Stroustrup. Average to
| incompetent people trying to select "very high level" people
| usually get scammed by the most imaginative resume bandits.
|
| 2) Programming languages are not as fixed as spoken languages,
| and "very high level" people are making more money in other
| languages, or less tedious languages.
|
| The article also uses language like "programmers" in a generic
| sense but the site is specifically for the financial services
| career field as are all the quotes. I've worked in financial
| services and the highly skilled people who can learn anything
| would never learn C++ because it doesn't pay nearly as well as,
| well, anything else in financial services IT departments. Someone
| made a huge architectural error in designing a system requiring
| the highest level C++ programmers but never telling HR to pay
| them enough to find any. If I were still doing financial services
| work I'd never learn C++, that would be dumb, I'll make a lot
| more money learning... anything else in that industry, or
| learning skills that transfer out of the industry.
|
| The article also mentions automotive, another example of a giant
| slow moving industry that underpays and over-Dilberts its C++
| programmers.
|
| What I enjoyed about my time in financial services is they
| understood their money depends on generous IT spending, they
| understood the value of documentation and code review, and it was
| a stable industry. Not perfect in an absolute sense but "more so
| relative to other industries". I would have to think for awhile
| if those values fit the C++ community. My immediate guess is "no"
| but I'm not certain, everyone liked the generous budget but the
| constant review and oversight was often a little excessive.
| deaddabe wrote:
| 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 Europe). Maybe as the old timers retire, job
| offers will align? Who knows.
| AtlasBarfed wrote:
| Isn't that nuts? It basically comes down to, if you're further
| from management, you're not valued.
|
| Oh, you can change the color of the button on my website?
| 200k/year!
|
| You eke out maximum performance from poorly documented devices
| and apis using obscure toolchains and custom built linux
| kernels to run on small chips that are the backbone of our
| business? 75k/year!
| shams93 wrote:
| I've seen that too, ironic since most scripting languages are
| written in c++, but languages such as go and rust are now self-
| hosted so there's finally meaningful aloternatives to either
| c++ or java/c# (in the case of go).
| maxloh wrote:
| Interpreted languages are also more flexible and easier to work
| with.
| mhfu wrote:
| Yep. I build glorified CRUD apps in NodeJS + React, my friend
| works on some embedded C++ stuff.
|
| - My working hours are way more flexible. I pretty much only
| have to attend meetings which are rare, so I can basically work
| whenever I want during the day. That means that I can go to the
| dentist and stuff like that without taking the day off. She has
| pretty strict hours.
|
| - I can work from anywhere, only requirement is decent internet
| connection. She has to go to the office because that's the only
| way she can actually test the code she writes for physical
| devices.
|
| - My salary is basically double of what my friend makes.
|
| She's currently learning JS so she can just move into web
| space. If someone can choose between easier job with much
| better salary, benefits and working conditions, they will do
| that without thinking, unless they reeeeeally like C++.
| colinjoy wrote:
| Probably less related to C++ as a language and more so an
| "embedded" issue or down to the specific industry that your
| friend is in.
|
| E.g., there are hundreds of C++ devs at my company that have
| the same work from home options and flexible hours as their
| frontend peers. So these jobs exist.
| PartiallyTyped wrote:
| Agreed. My friend - a kernel dev - and I - a non-
| specialized SDE - have the same benefits and flexible
| hours.
| electrondood wrote:
| > glorified CRUD apps
|
| Why is API design/backend engineering the only software
| discipline that gets maligned like this? These are bread-and-
| butter operations. I don't mean to attack you, just noting
| that I never hear anyone talk about mobile development in the
| same way, for example.
| Tomis02 wrote:
| > Why is ... backend engineering the only software
| discipline that gets maligned like this?
|
| Where do I even begin? The intrinsic difficulty of most
| backend problems is very low - read some customer data,
| save it to a database, call an external API, send data back
| to customer. The only effort you should have to put in is
| fighting boredom.
|
| The web dev industry managed to overcomplicate this task to
| the point where even small startups targeting niche markets
| have architectures inviting race conditions over
| distributed systems with tens/hundreds/thousands of working
| parts.
|
| It doesn't have to be like this. The problem is that your
| average web dev doesn't know how to scale down (optimize
| for space/memory/disk consumption), so instead they scale
| up (more computers). Scaling up isn't necessarily a problem
| if you know what you're doing, but I've seen a bunch of
| super-principal engineers regurgitating the popular scaling
| up buzzwords without actually understanding the tradeoffs.
| They choose a technology because Google is using it.
|
| It's not fun to fix deep systemic problems in distributed
| systems when the system has already been running for a long
| time, and there's a large number of devs working on it. You
| can't just say "ok, everyone stop working, for a while,
| we'll take a couple of months to rewrite everything, the
| customer can wait".
|
| What's worse it that this type of issues would've been
| obvious from the very beginning to anyone mildly curious to
| imagine what the future of such a system would look like.
|
| Another type of common issue is slow queries, and the
| common "solution" results in eventual consistency.
|
| I'll stop now.
|
| > I never hear anyone talk about mobile development in the
| same way
|
| Mobile development is just as bad, maybe worse. One overly
| complicated framework (Android), and another one that's
| fenced-off to non-Mac developers.
| mhfu wrote:
| It's not maligned. I've worked on some complex backends
| some time ago and I would never call those glorified CRUD
| apps. But my current project is basically Node backend with
| almost zero business logic. You hit GET endpoint, it
| returns someORMRepository.find('events').where({ category:
| 'FUN' }). That's it. React side displays a table with some
| basic sorting and filtering. Editing and creating and entry
| is just a basic form. I don't see how else could I call it,
| it's not that much different from CRUD demos you see in
| blog posts.
| philote wrote:
| Why does that seem maligned to you? I don't see it as
| negative at all, just descriptive.
| [deleted]
| colinmhayes wrote:
| backend web dev can feel tedious/monotonous imo.
| epolanski wrote:
| > Why is API design/backend engineering the only software
| discipline that gets maligned like this?
|
| It's web development in general.
| WorldMaker wrote:
| A lot of CRUD app development feels like tedious,
| repetitive busy work. Data entry was a solved problem in
| COBOL if not earlier, it's not gotten any harder in the
| decades since, it's just gotten more tedious.
|
| There are generic data entry tools that solve the entire
| class of problems in that space. In web tooling there are
| things like Django's Admin app. In "the ancient world"
| there is Excel for good and bad and ugly. But those aren't
| "branded" enough. Those aren't "experiences" that some UI
| designer has sweated and cried over until they were
| beautiful. Those "don't understand the domain" or "don't
| support our processes" or "don't know that we are a special
| snowflake with special snowflake data" hard enough.
|
| So you just rebuild the same types of things over and over
| again every time the UI designers get bored or the company
| decides to use a slightly different version of the same
| data. Sometimes it can feel a bit Sisyphean.
| klabb3 wrote:
| I think there's truth to this but you're glossing over
| details that are critical. If the amount of variation
| between products were countable and predictable as you
| paint it, then you'd only need designers and a cms
| specialist who can configure the product. As a web shop,
| this is much cheaper to do. There are tons of website
| builders today which has saturated the "simple" market,
| but "intermediate" customers have small variations that
| still need custom integration work.
|
| All in all, saying that dev work is repetetive is a hard
| sell, because if it was, you could just automate it. And
| we clearly haven't automated even the space of medium-
| complexity web apps yet.
| WorldMaker wrote:
| I pointed to two clear examples where we as an industry
| _have_ automated it (Django 's Admin app, Excel), and I
| could name tons more (Access, Power Automate, InfoPath,
| Power Apps, SharePoint Apps, SharePoint Lists, and those
| are just the Microsoft side of the list; you mention CMS
| specialists and we could list out of the box CMSes for
| days).
|
| > still need custom integration work
|
| Define "need" here. I already threw some shade at this by
| accusing many companies of thinking their every need is a
| special little snowflake that needs lots of custom tweaks
| and custom specifics. In my practical experience so much
| more of that is "want" rather than "need". They _want_ to
| feel special. They _want_ to feel like they have control.
| They don 't want to pay for the cheap out of the box CMS
| because it might imply to their executives and
| shareholders that their entire _business_ is cheap and
| easily automated.
|
| Some of these CRUD apps are truly "John Hammond syndrome"
| apps: they want the illusion that no expense was spared.
| (And just like John Hammond sometimes confusing building
| out the gift shop and adding fancy food to the restaurant
| in the Visitor Center with spending enough on redundancy
| among the critical operations work and staff.)
| FredPret wrote:
| The same can be said for dentists or architects or
| chemical engineers or whatever. Teeth and houses and oil
| refineries are "solved" problems in that we know how to
| do it.
|
| But each instance is a little different. Each customer
| wants _their_ flavour of the problem solved.
|
| Long story short: don't get into a line of work if you
| don't like churning out multiples of the same thing for
| years.
| WorldMaker wrote:
| > The same can be said for dentists or architects or
| chemical engineers or whatever.
|
| - Dentists have dental hygienists that do the day-to-day
| grunt work so that dentists can focus on the real
| problems/exceptional cases (cavities, root canals, etc).
|
| - Architects build the plans, but they leave it to
| construction workers to actually construct the project.
|
| - Chemical engineers generally work with staffs of
| chemists and other roles that the take the engineered
| solution and apply it day-to-day.
|
| Right now, software uses the same job titles "for
| everything". There's (perhaps intentionally) no
| differentiation between the people expected to solve the
| hard problems/engineer the tough solutions and the people
| hired to plug-and-chug their way through their 15th yet-
| another-CRUD-app that year. There are complaints in the
| surrounding threads even that some of the "drone work"
| pays better salaries and has better hours/corporate
| cultures than the harder stuff. It's an interesting
| "upside down" situation compared to even just the three
| fields specifically referenced here.
|
| I went to an engineering school with the expectation that
| I would be doing software _engineering_ not just in name
| but in role, but most of the jobs I 've ever worked were
| paying me to do not that. I certainly know friends who
| are chemical engineers that _also_ perform the role of
| chemists for their companies, but those are clearly
| distinct enough job descriptions with a big enough salary
| distance that those companies _know_ that any hours my
| friends put in as chemists rather than their hired job is
| _over-paying_ those hour rates by a considerable enough
| amount that they have reason to hire cheaper chemists. I
| have _never_ seen a software job consider that they may
| be hugely over-paying a software engineer to do
| "software development grunt work". Without truly separate
| job titles and salary considerations that is forever
| going to be opaque to the accountants at companies.
|
| Long story short: other professions clearly delineate
| between jobs that are (creative) problem solving and jobs
| that are more "grunt work" like Ikea-assembling CRUD
| apps. Why don't we?
| jonnycoder wrote:
| As someone who has done .NET, C++ embedded, Python and
| NodeJS, I have to say that picking up NodeJS and creating
| APIs at scale with full automated nightly test suites
| using docker and postman/newman was very easy to learn
| and very fun. Python is up there as well but I had to
| work on Django and not some of the more simpler api
| frameworks that looks nice.
| mschuster91 wrote:
| > Apart from finance, pay is lower than web languages. And
| finance is small.
|
| And it's blasted to hell with bureaucracy, red tape, toxic work
| environments and a reputation for having to deal with
| infrastructure best described as "fossilized". Banks have no
| one to blame but themselves (and maaaaybe a bit the sometimes
| insane requirements of financial regulation agencies) for being
| unable to attract programmers.
|
| At least in Germany, the fintechs have never had much trouble
| attracting developers... so it's not the finance industry
| itself, here in Germany it is definitely a culture problem in
| the established banks that historically have treated IT purely
| as a cost center instead of the integral part of business they
| are.
| zabzonk wrote:
| i have worked for several investment banks, and have always
| been highly paid, and had top-notch hardware and software to
| work with - i am sure that most competent banks realise that
| they are basically software hosts.
| mschuster91 wrote:
| Investment banks aren't your typical consumer banks though
| - less red tape (because they're not consumer banks), less
| historical baggage (consumer banks have accounts that are
| sometimes well over a century old, which makes everything
| that touches account data incredibly sensitive as the data
| needs to be always consistent), and way more money
| available. There's a reason why a lot of advances in
| communication came from the needs of the investment banks,
| particularly specialized hedge funds / "quant banks".
| PragmaticPulp wrote:
| > 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 the
| embedded side of the product didn't get the same level of
| attention.
|
| It's like embedded somehow became an afterthought in the
| industry. Perhaps because it's the only part of the system that
| doesn't have a highly polished UI layered on top of it? Over
| the past decade I've witnessed multiple companies over focus on
| anything that goes well into slide decks (UX mock-ups,
| animations, etc.) or generates vanity metrics (number of
| backend servers, requests per second to the cloud) while
| ignoring anything that doesn't have a visual pop to it
| (embedded firmware)
| larve wrote:
| 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.
| eschneider wrote:
| Yeah, I sorta specialize in that whole IoT firmware
| update/fleet monitoring/make sure everything at the edge runs
| smoothly end of things, and if you find a company that
| realizes that this is something that MUST work smoothly if
| they're going to scale, then it's a very sweet place to be.
| Even better, that sorta work combines low-level C++ with lots
| of back-end web service work, so you're never 'just' a C++
| programmer.
| ryandrake wrote:
| Many hardware companies still see software as just another
| line item on the BOM: Like a screw or a gasket. It's
| something you build cheaply or buy from a supplier and
| sprinkle it on the product somewhere on the assembly line.
| These hardware companies have no concept of typical measures
| of software quality, building an ecosystem, release
| management, sometimes even no concept of source control. They
| tell an overworked embedded software engineer: "Go build
| something that barely meets these requirements, ship it, and
| then throw the scrap away." like metal shavings from their
| CNC machine.
| jack_h wrote:
| At a previous company our firmware was literally called by
| a part number. So I would regularly work on the repos
| 5400-520, 5400-521, 5400-524, 5400-526, etc.
| goalieca wrote:
| Thanks for bringing up weird memories. I remember
| software not having a name and version but a part number.
| As if it wasn't living and evolving as it needed to be as
| a networked firmware.
| ryandrake wrote:
| I remember an embedded company I joined; when I asked how
| they manage releases, the eng manager said, "well, we
| find an engineer who has a copy of the source code that
| can successfully build with no errors, copy it off their
| workstation (debug symbols and all), and send it to the
| factory to get flashed onto devices." Total clown show.
| sumtechguy wrote:
| 'sometimes we check it into sourcesafe' in 2018...
| kabdib wrote:
| One large phone manufacturer maintained a room full of
| PCs, each machine configured to build for one model of
| phone.
|
| I don't know if they kept backups. I wouldn't take that
| bet.
| HeyLaughingBoy wrote:
| Assigning a part number to firmware is perfectly normal.
| It's part of the Bill of Materials for the product.
|
| What is not normal is referring to that part number
| anywhere except on the BoM.
| commandlinefan wrote:
| > typical measures of software quality
|
| To play devil's advocate - are there any (useful) measures
| of software quality? Even this place is mostly programmers
| and we can't even agree whether we should be writing unit
| tests or not.
| marmetio wrote:
| Sort of. There are accurate measures with verifiable
| predictive power. But useful depends on cost/benefit,
| which in turn depends on ability to implement and market
| forces.
|
| There's a company that looked at reducing critical
| defects from a sort of actuarial perspective. They have a
| few decades of cross-industry data. I've used their
| model, and it works. If you don't need a numerical
| result, you can just read the white paper about what's
| most important [1].
|
| So to partially answer your question: unit testing
| reduces defects, but reducing defects might not be worth
| the costs to you.
|
| And defects might not be the only thing that matters.
| There are other measures of goodness, like
| maintainability, which complicates the answer. You'd have
| to collect your own data for that.
|
| [1] https://missionreadysoftware.com/articles/
| goalieca wrote:
| I'd say for micro services and large distributed system,
| you do need a pyramid of testing with most covered at the
| unit level. The system is just too large and continuously
| changing as all the different versions of services
| release.
| Palomides wrote:
| this is grimly funny to me because where I work, software
| is a literal line item in the manufacturing BOM, each
| release gets a part number and is physically shipped to the
| factory
|
| it makes some sense, but the company mindset about the role
| of software is very clear
| bsder wrote:
| > 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
| the embedded side of the product didn't get the same level of
| attention.
|
| Why? The issue is that you have to actually ... you know ...
| _PLAN_ when you have an embedded device.
|
| You can churn the app and the web and the backend infinitely
| so there is no penalty for doing so. If you take that
| attitude and apply it to embedded you wind up with an
| expensive pile of scrap.
| thewebcount wrote:
| There was a time in the late 90s/early 2000s where this
| happened to driver development on the (Classic) Mac.
| Companies would make some USB device and get a reasonable
| driver made for Windows (I assume - I wasn't using Windows at
| the time). Then they would say, "Well, MacOS is 10% the
| market of Windows, so we'll pay 1/10th for someone to develop
| a driver for this." But it turned out that USB worked
| completely differently on the Mac from how it did on Windows,
| so none of the Windows code was relevant at all for the Mac
| devs. They would either get what they paid for (which was
| terrible for users) or they would not get a Mac driver. This
| is around the time I stopped buying any device that required
| installing a driver. Many of these devices didn't really need
| one because they were regular USB-spec devices (keyboards,
| scanners, etc.) To this day, I will not install a driver for
| a fucking mouse. Why would that be required?
| Jtsummers wrote:
| "Programming is just typing" was a typical management refrain
| when I was in the embedded field (more properly, now I'm
| adjacent to it). It was frustrating. Computer scientists and
| programmers aren't Real(tm) Engineers so they don't deserve
| as much money. They can't be in charge because you can't have
| engineers answering to non-engineers (ie, very few leads let
| alone managers coming from the software side). Which leads to
| a culture that's overly hardware centric with insufficient
| leadership/management understanding of what software actually
| entails.
|
| Also, "This doesn't meet the current requirements, fix it
| with software!" The best one was when the case wasn't
| waterproof... How the fuck is software supposed to fix that?
| They literally expected the software team to work magic. A
| lot of pushback got that requirement kicked back over to the
| mechanical engineering team to address, but it took months.
| Moronic.
| AtlasBarfed wrote:
| It might also be that the management chains in embedded are
| likely former engineers or EE people. In Web you get a lot
| of management interfaces where the boss can't do their job:
| that's the perfect recipe for high pay.
|
| In embedded and other non-software engineering but
| engineering firms, the management is typically engineers
| that CAN do their subordinates jobs, they just don't want
| to.
| Jtsummers wrote:
| That's what I was getting at with this:
|
| > They can't be in charge because you can't have
| engineers answering to non-engineers (ie, very few leads
| let alone managers coming from the software side). Which
| leads to a culture that's overly hardware centric with
| insufficient leadership/management understanding of what
| software actually entails.
|
| In hardware-centric orgs, software developers are a small
| step above technicians in their pecking order, sometimes
| below. The pecking order itself is annoying enough, but
| when you switch from designing your own ASICs to buying
| COTS dev boards and primarily only adding software to it,
| you're not really a hardware company anymore. But it'll
| take another generation for them to realize it, or a
| severe crunch if someone comes along and realizes that
| they can pay embedded devs $200k+ and eat the lunch of
| half these companies.
| kaylynb wrote:
| This has been my experience in the US. C++ is my favorite
| language. I learned programming using it in the mid nineties. I
| still keep up with developments although I wouldn't consider
| myself the most skilled with it anymore.
|
| The only job I've ever had that used it was a civil engineering
| company in a small city in the deep south, and it was mostly
| just C. The pay was good for the area, but nothing spectacular.
|
| I moved to Seattle and the only C++ jobs were at FAANGs, and
| only a small portion of jobs at those companies. I worked at
| two FAANGs and only used Java and C#. I learned frontend web
| stacks largely due to job flexibility and it almost always pays
| the best vs amount of stress/work needed to put in.
|
| Yeah I could probably write C++ at <insert FAANG> for 2x the
| salary but I'd also have to work 80h work weeks and deal with
| FAANG internal politics and sabotage from coworkers, depending
| on FAANG and which variation of "don't call it stack ranking"
| they use this year.
|
| On the other hand I can use TypeScript and work from my home
| office. I've been considering moving back to the south just
| because much lower living expenses, family, and availability of
| remote work for web stacks. I can't get that with C++.
| speby wrote:
| 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?
| Leherenn wrote:
| In embedded you sell hardware, with web you sell software.
| Software scales a lot more than hardware, thus more revenues
| per employee.
| speby wrote:
| That makes complete sense! I wasn't even thinking about
| that angle.
| thedracle wrote:
| I started as an embedded software engineer in the early 90's,
| and at the time there were lots of well paying jobs compared
| to other software engineering diciplines.
|
| In the 2ks/10's, at least in my area, embedded jobs dried up.
| Mobile development produced a lot of very high performance
| SoCs that were cheap, and had high quality already developed
| middleware layers (Android for instance). They sort of
| conquered a lot of the embedded media processing space I was
| an expert in.
|
| As a result I jumped ship to mobile, but it was much higher
| level programming far away from the SoC, and most of the
| lower level code was being written in China/South Korea.
|
| This basically meant for the engineers that weren't able to
| shift, they basically weren't scouting around for, or finding
| other jobs (in general).
|
| So even though there is a small pool of engineers with these
| skills, a lot of people left the embedded space at a time
| when some of those jobs are starting to shift back, leaving a
| shortfall, but also a pay gap.
| ryandrake wrote:
| Yea, I moved from embedded to mobile (iOS) development
| pretty quickly. Similar problems/constraints but the
| tooling was an order of magnitude better. No more cobbling
| together non-working cross-compilers from some vendor's
| crappy BSP and praying they produced binaries that worked.
| benttoothpaste wrote:
| My last C++ job was for a robotics company a few years ago (pre
| pandemic). The job was not very "embedded", but quite
| challenging - processing noisy images from lidars, etc. I
| worked 60 hour weeks and my salary was 80k or so. Then I
| realized I can get twice as much just writing Python micro
| services. So I became a Python developer instead. Much less
| stress and a lot more free time too.
| chrisseaton wrote:
| > Because Python pays more. Or Javascript. Or Ruby.
|
| But these are all implemented in C++ or C? Those aren't low-
| paying jobs.
| fiedzia wrote:
| > But these are all implemented in C++ or C?
|
| Mostly, but Rust is increasingly replacing them.
| eddsh1994 wrote:
| Which of those languages are being rewritten in Rust?
| fiedzia wrote:
| 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.
| maxloh wrote:
| 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.
| chrisseaton wrote:
| > 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.
| cortesoft wrote:
| No one is paying the implementers of those languages
| chrisseaton wrote:
| > 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.
| KptMarchewa wrote:
| https://discuss.python.org/t/official-list-of-core-
| developer...
|
| >In my latest talk, I computed that we have 2 developers
| paid at full time to maintain Python: I am full time,
| Barry, Brett, Eric, Steve and Guido have 1 day per week
| if I understood correctly.
|
| Now from what I understand situation is way better, but
| still - that's what it looked like just three years ago,
| when Python already had millions of people writing code
| in it.
| [deleted]
| snapcaster wrote:
| 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
| chrisseaton wrote:
| Yeah - but it's not 'no one'.
| Supermancho wrote:
| I'm not sure how being pedantic changes the perception,
| or state, of the industry.
| cortesoft wrote:
| Sorry, 'no one' is clearly an exaggeration. "Not enough
| to affect the job market" is a better way of putting it.
| [deleted]
| dspillett wrote:
| OK, few are actively recruiting for people on those
| projects, as a proportion of the whole job market. A few
| juicy jobs there and a huge pile of less well paying ones
| means that any average is going to be low. The existence
| of those roles is great for those that have/get them, but
| this doesn't help the wider pool who need to use other
| tech to get the better wages - a situation that results
| in fewer newly training in c++ because those outside the
| pool see the low average.
| heinekan wrote:
| Can confirm the interest of workers leaving the embedded space.
|
| I am a embedded C++ engineer and it feels like I'm watching all
| my friends who work building web apps have fun on the other
| side.
|
| - More companies/job openings
|
| - Higher salaries
|
| - Flexible working
|
| - More interesting technology/problems
| ojl wrote:
| I don't know, I guess it depends on location and such. I work
| as a C++ dev with computer vision related stuff. I have an ok
| salary and very flexible working conditions. And I haven't
| seen any web related jobs in my region which seem
| technologically more interesting.
|
| You are correct about number of job openings though..
| jakesgates wrote:
| I'll second this, I work as a low level C dev on embedded
| stuff. Good salary for the region, company pays embedded
| software devs at the same rate as high level app and web
| devs, and have somewhat flexible working conditions. This
| is just an anecdote I know, but I am very surprised at the
| general consensus at how bad the embedded positions are, it
| hasn't been my experience or my peers at least.
| eklitzke wrote:
| This might be true for embedded C++ programmers, but it's not
| true at FAANG or finance companies, which accounts for a lot of
| C++ programmers. I'm in San Francisco and I wrote mostly
| Python/Go at web companies for the first 10 or so years of my
| career, and write C++ at a FAANG now. I'm getting paid
| significantly more now than I was before. At my previous job
| where I was writing C++ I was making $286k in cash ($220k base
| salary + 30% bonus target) plus generous stock compensation.
| Most people writing Python, Javascript, or Ruby are not getting
| paid that much in cash even if they're working at a unicorn
| startup in SF.
| brrrrrm wrote:
| You've presented a false dichotomy between "web" and "embedded
| systems".
|
| C++ fuels the engines behind Python and JavaScript. Databases,
| compilers, machine learning libraries: all C++ and actively
| maintained.
| _aavaa_ wrote:
| But what's the ratio of people work implementing and
| maintaining these things at the C++ layer versus those using
| the python layer?
| jasmer wrote:
| It's a resonant issue: if everyone is taught Python, it's the
| tool they will reach for.
|
| And of course, Python is much more broadly applicable.
|
| I don't like to develop in C++ because it's a tiresome mess of
| issues that don't exist in modern languages.
|
| I don't care about the newer variations or whatever, I still
| can't do basic things or pull in a library to do it 20 years
| later so no thanks.
|
| That said - it's not going to go away.
|
| While Rust is nice, I just don't see it replacing C/C++ for a
| long time due to abi incompatibility etc..
|
| C++ does require more experience, and it needs to pay well or
| companies won't get the talent.
| thedracle wrote:
| I'm really surprised at how stable and widely supported
| Rust's FFI is.
|
| I have several C++ projects that integrate a portion written
| in Rust, where the Rust project produces a .a file that is
| ultimately linked with clang into a larger C++ project.
|
| I definitely agree Rust has a long road to adoption in
| embedded/low level systems, and particularly areas with
| custom compilers/toolchains that rely heavily on system
| specific undefined behavior.
|
| But it's a lot closer than I had thought it was a year or so
| ago.
| nprateem wrote:
| And C++ is difficult & confusing. Other more modern languages
| have easier toolchains and fewer gotchas.
| zabzonk wrote:
| a few issues here - c++ is not used that widely in embedded
| (most prefer c or a small c++ subset). and ruby? i can't
| remember the last time i saw a post about ruby here. and
| finance is huge.
| [deleted]
| stu2b50 wrote:
| Ruby still has relevance as it was the lingua franca of the
| 2010s ish startup scene. These days those startups have
| become veritable big tech companies in their own right -
| Stripe, Uber, AirBnB, and so forth. While many of those
| companies have started integrating other languages they still
| have massive legacy ruby codebases and demand then for ruby
| engineers.
| zabzonk wrote:
| all those companies you mention seem to me to have a 50/50
| chance of going down the tubes. not because of their use of
| ruby, of course. still, i don't see any company started
| today to base their software on ruby. probably just me
| being wrong.
| ativzzz wrote:
| as a rails dev, if I were to start a new project today I
| would still pick rails. It makes building web apps a
| breeze. The technology is mature, stable, active and
| still staying modern in terms of integration with modern
| JS
|
| you start running into problems as you scale, but the
| reality is you will run into scaling problems regardless
| of what technology you use, and the ability to move
| quickly and iterate is much more important for new
| projects than solving scaling problems before they exist
| DeathArrow wrote:
| >as a rails dev, if I were to start a new project today I
| would still pick rails. It makes building web apps a
| breeze.
|
| It's also a breeze if you use .NET and it will run
| circles around the Ruby app.
| ativzzz wrote:
| haha but then I have to learn the entire .NET / windows
| ecosystem which is a huge jump considering i've only ever
| developed on mac/linux. I am using wsl now though
|
| and running circles won't matter because for most web
| apps the DB is usually the bottleneck anyway
| DeathArrow wrote:
| But you can use .NET on both Linux and Mac. As for DB
| being the limit, usually that's only the case for simple
| CRUD apps. In microservices and high load apps,
| performance matters.
|
| .NET is just one example. It could be Go or Java.
| ativzzz wrote:
| microservices start being useful when your monolith
| becomes too large for your engineering department to work
| on simultaneously. If you force good engineering
| practices and quality code reviews, you can scale this up
| to at least 100 devs. Microservices are more about
| Conway's law
|
| high load apps I agree with, pick the technology that is
| appropriate, but again, for new projects I would say any
| technology that gives you speed of development (like
| rails) is far far far superior to speed of the
| technology.
| germandiago wrote:
| This is the reason why I will pick Django for my next
| web: iteration time > scaling problems especially at the
| beginning. Same for Rails.
| clum wrote:
| It's also the companies that use C++ in my market (Embedded,
| Germany): They are either "old" industries (cars, car-parts,
| industrial machines, military equipment, embedded stuff) or
| consultancies working for these companies. Very few of them
| have any real flexibility nor do they care about their
| employees' wishes much. I have been looking for a 20h/week
| remote job (I have 5+ YOE) in this field for a few months and
| basically all offers were crap in one way or another.
| Negotiating your contract beyond salary and vacation days is
| extremely non-standard. Working remote is not a thing - best
| you can do is work from home, often with clauses allowing them
| to cancel this agreement any time, or with very weird
| restrictions around your workplace. There is tons of red tape
| in every single bigger company. I'm still deciding between two
| offers, but it is very likely I will leave the C++ Embedded
| field and work in the python market in the future.
|
| I am at a bit of a loss here. On the one hand these very
| companies cry publicly about a lack of skilled workers, on the
| other hand you have to fight hard to get your market price and
| they will not budge on downright immoral clauses (such as not
| getting paid for x amount of overtime per week) or remote work.
| FredPret wrote:
| It's survival of the fittest in the market and sounds like
| these companies aren't it
| Sakos wrote:
| Sounds like a completely different world from where I work in
| Cologne. We're having trouble finding good Java developers,
| so we're basically dropping requirements left and right.
| We'll even interview people without a resume and we're far
| more flexible on remote work than we are in the rest of the
| company.
| germandiago wrote:
| Immoral clause sounds to me like too much. If conditions are
| bad, just leave. They will have to change them eventually,
| that's it.
| jart wrote:
| Isn't it common for C++ devs in finance to make seven figure
| salaries?
| sentinalien wrote:
| Not really no, 7 figure roles are few and far between
| zabzonk wrote:
| but definitely 6 figure - i know i was, and that's going
| back years
| bee_rider wrote:
| The difference between 6 and 7 figures can be 7 figures.
| I guess you must mean a high 6 though?
| 22SAS wrote:
| No. I work in HFT and this happens in only two cases:
|
| 1. At top-tier firms like HRT, Citadel Securities, Jump, TGS,
| RenTech; there are a decent amount of C++ devs making
| 7-figures. In many cases, it may depend on how profitable
| their desk is.
|
| 2. At most other firms (mine included), only very senior devs
| are making 7-figures. These are people managing or overseeing
| many teams.
|
| This BS that HFT C++ devs make craptons of money has been
| spread by tech bros and college kids, who have never worked
| in HFT.
| hnews_account_1 wrote:
| There are no 7 figure dev roles in finance except in very
| select hedge funds where one time bonuses in 5 or 6 years may
| be that large. 6 figure is the norm. At 7 figures, you're
| likely in management and not working on technical details.
| kevstev wrote:
| 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...
| 22SAS wrote:
| Banks in general pay a lot less for C++ devs than prop
| trading firms do.
| kevstev wrote:
| 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 writing C++,
| different story, but they were paid entirely for their
| research/alpha generating ability, C++ was just a tool
| they used to get there. In fact, hearing about their
| hiring process, it was mostly math questions, I am not
| even sure there was a big in depth technical portion to
| their interview loop.
|
| Similarly, there were some AI/ML guys that were rumored
| to be hauling it in, but this was not for their tech
| skills- though they were doing mostly python, it was for
| their AI/ML specific knowledge. As was kind of typical at
| that place, and most places like it, those guys I think
| all flamed out and were let go by the time I left. While
| its not easy to "score a deal" and get promised a very
| high package for a year or two, its actually much harder
| in those types of roles to actually keep your seat there.
| But... if you are actually producing models that generate
| alpha/profit for the firm, then you are golden.
|
| AI/ML was really just a specific manifestation of a
| larger trend of if you were on the bleeding edge of a
| capability that the firm wanted- IE had invented it, or
| were a very early successful adopter, my firm would have
| been welling to pay well above typical market to get
| that. Think along the lines of cloud (2016ish),
| Kubernetes (2017/18ish), "big data" (2016ish) capability,
| etc... an alternate route would be to have had
| successfully engineered change in an org to adopt
| something like real SRE. Even those types of things, I
| don't believe anyone was over 7 figures, but maybe?
| Regardless, the typical path there would be to kind of
| "burn and churn" those types- IE they build it, maybe its
| even quite successful, and then thats your niche for the
| rest of your time there (which is not what most leader
| types want), or you don't succeed and just get pushed out
| pretty quick- SRE as a concept was something my previous
| firm tried several stabs at hiring guys from Google for,
| but they just never made any real inroads on.
| 22SAS wrote:
| 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.
| opportune wrote:
| A lot of C++ jobs are at FAANG companies. At least at the ones
| I've worked, nothing serious (ie in prod) is implemented in
| Python or Ruby. It's Java for stuff that doesn't need to be
| fast, C++ for stuff that needs to be fast, and Go for random
| stuff where people were able to shoehorn it in.
|
| I think the problem is more that asking someone to accept low
| pay to work in C++ (one of the hardest languages to be
| productive in) doesn't make any sense. If I'm good at software
| and know C++ I'll work at a FAANG, AI company, self driving, or
| HFT/Hedge Fund for 3x-10x what a random C++ embedded role would
| pay.
| UncleOxidant wrote:
| 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 developer needs to
| know a lot about both software and hardware.
| BeetleB wrote:
| Yes - I used to program in C++, and left it for another job.
| 2 years later, when looking for other opportunities, I
| realized how much of the small details in C++ I'd forgotten,
| and didn't want to go back to all those minutiae unless it
| paid more.
|
| It's a real relief to drop that cognitive load.
| spamizbad wrote:
| I'm about a decade removed from a C++ shop and I disagree
| with this.
|
| I've found C++ shops have "lower" standards for C++
| developers. I'm putting "lower" in quotes here because I'm
| talking relative skill within a given language. It just seems
| way more common in C++ shops to have situations where "20% of
| the developers do 80% of the work". This isn't to say there's
| dead weight in Python/Ruby shops, but my experience in the
| C++ world was there was always a small group of developers
| doing most of the work and this is considered _normal_
| whereas the same situation in a Python /Ruby shop would be a
| major crisis.
|
| Despite the demand, if you're a low output Python/Ruby dev
| you'll likely struggle to hold a career together; hiring will
| be a slog and you'll get squeezed out of orgs with PIPs every
| 6 months. The same low output C++ developer could probably
| stay gainfully employed once hired.
|
| Hopefully this fact might encourage others to pursue C/C++
| jobs. There is zero expectations towards being a "rockstar" -
| if you know the fundamentals and can plod through work at
| whatever pace you're comfortable with there's probably a job
| out there for you.
| jonnycoder wrote:
| 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.
| ativzzz wrote:
| Yup and as we know we don't get paid based on the difficulty
| of the problem we are solving.
| analognoise wrote:
| I've discovered this and am trying to move into pretty much
| anything web related.
| cmrdporcupine wrote:
| 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.
|
| The problem is I really like writing C++ (and Rust, etc.)! So
| I'm cultivating other "systems programming" type career paths;
| DB internals, have always fascinated me, so I'm trying that
| direction. Working fulltime in Rust now, but it's hard to find
| work there that isn't crypto-tainted.
|
| Other people have pointed out that lower pay in embedded has to
| do with the influence of EE salaries. Which are sadly lower
| than they rightfully should be.
| Aromasin wrote:
| I'm really hoping the salaries for EE type roles start to
| match software as the grey beards start to retire and talent
| becomes scarce. We've got a legion of grads going into CS,
| but EE classes are a fraction of that. Despite that, software
| roles are often more than double the salary. Any role I go
| into as an EE/Embedded Systems engineer, I'm more often than
| not the youngest by 20-30 years. I wonder how the industry in
| the West is going to survive it, beyond hiring contractors
| from India/South Asia.
| georgeburdell wrote:
| EE won't go higher, SWE will go lower
| Retric wrote:
| Alternatively, web is generally more valuable. You don't
| buy a new washing machine because the current firmware
| sucks, but you will shop somewhere else if Newegg's
| website is terrible. That relationship is generally true
| where people rarely test embedded software until after a
| purchase, but people tend to jump ship more frequently
| online.
|
| Net result a lot of critical infrastructure and devices
| suck as much as possible while still getting the job
| done.
| Negitivefrags wrote:
| I'm building a house at the moment and I have been
| insisting that I am able to actually test all the built
| in appliances with power to see if the software is
| garbage.
|
| I have found that most of the high end brands have a
| completely horrible user experience. Miele is the worst
| I've tried, and I found that as you go up the price range
| even inside that brand the experience gets worse.
|
| The top end Miele induction cooktop takes over 5 seconds
| to boot up before you can even turn a hob on. The
| interface has a second of latency on presses. It took me
| probably 20 seconds to work out _how_ to turn a hob on. I
| happened to be with my mother at the time and I asked her
| to try to work out how to turn a hob on and she had
| failed after 1 minute of trying and gave up and asked me.
|
| It looks nice though.
|
| The thing I find the most infuriating about it is that my
| attitude towards this stuff is just not understood by
| designers at all. They complain at my choices because the
| Miele appliances which they specified are "better
| quality". And yet I feel like they can't have actually
| tried to use them because as far as I can tell the
| quality is total garbage.
| ryandrake wrote:
| The mere idea of waiting for a kitchen appliance to "boot
| up" makes me angry. How did we normalize this madness?
| Telephones, TVs, car engine instruments, HVAC
| thermostats, why can't any of these be instant-on like in
| the 80s? Apply power and it starts working is a basic
| design principle.
| riskable wrote:
| Meh. Bootup time is irrelevant if the thing is always on.
| Many "dumb" microwaves won't let you use them until you
| set the clock after a power loss which creates an
| artificial "boot up time" of 5-120 seconds (depending on
| how complicated the procedure is; I remember microwaves
| that had absolutely obtuse clock-setting procedures).
| Negitivefrags wrote:
| In the case of this cooktop, it was not always on. You
| have to boot it up every time you go to use it.
| KerrAvon wrote:
| Good to know about Miele ranges -- this would certainly
| infuriate me. I wonder if their higher end dishwashers
| have the same usability problems.
| pencilguin wrote:
| Most dishwashers stay on all the time, drawing watts
| 24/7. That could be microwatts, but that might cost an
| extra dollar.
|
| Probably the cooktop boots up anew each time because
| otherwise you would have to be able to reset it when it
| crashes.
| VBprogrammer wrote:
| Slightly off topic but imagine an induction cooker with
| the original iPod control wheel as it's power control.
|
| We opted for a gas hob when we installed our kitchen.
| Mostly because I like the controllability when cooking.
| Obviously it's a nightmare for health and the environment
| but man it makes cooking easier.
| dudeofea wrote:
| how is it a nightmare? if you aren't getting that energy
| from natural gas, you'd mostly get it from a CO2
| producing power plant, with efficiency losses going from
| heat (steam) -> electric -> heat (cooktop)
| Retric wrote:
| Even Gas cooktops without a pilot light are surprisingly
| inefficient with under 40% of the energy ending up in
| your pan. (Which is why the air several feet above the
| pan is so hot.) On top of this you end up venting air
| your HVAC system just used a lot of energy to make
| pleasant outside and/or breathing noxious fumes from
| incomplete combustion so Carbon Monoxide, NOx,
| formaldehyde etc
|
| Induction stoves powered by natural gas power plants are
| more efficient than directly cooking with natural gas
| plus you can use clean solar/wind/nuclear/hydropower or
| oddballs like geothermal.
| cameronh90 wrote:
| Because about 45% of our (UK) electricity doesn't emit
| carbon. Gas is also really terrible for indoor air
| quality.
| robocat wrote:
| Touch controls on induction cooktops/hobs are almost
| ubiquitous, and they have extremely poor usability in my
| experience. Liquids cause problems, and you need to be
| very careful not to move a pan or any utensils over the
| controls, or brush against them while concentrating on
| cooking. Apart from the other awful usability issues with
| the UI or icons.
|
| I did a survey of all the cooktops/hobs I could find in
| my city, looking for something that would suit my elderly
| mum, and I didn't find a single unit that was _usable_.
| Fortunately a salesperson knew of a recently developed
| "cheap" model from a noname brand, which had individual
| knobs, so I ordered that, it arrived an month ago so I
| got it installed, and it has worked very well for my mum.
|
| Usability is not something that most people know to look
| for when making purchases, so most whiteware ends up with
| a hideous UI. People will buy shit, then complain, but it
| doesn't change their future purchasing habits (e.g.
| looking for features, especially useless features!)
|
| I bought a middling brand microwave with knobs that has
| reasonable usability, despite providing all features. The
| iPhone is another possible counterexample, although I
| fucking hate many of their usability decisions (remove
| all multi-tasking shit from my iPad - I only ever
| initiate it by mistake and I _always_ struggle to revert
| my mistake - fucking floating windows and split windows
| and fucking ... at top of the screen).
| VBprogrammer wrote:
| The ability to clean the cooker is the only advantage of
| touch controls. I don't know how well the original iPod
| touch wheel would hold up in that environment but from a
| usability point of view it was excellent.
| WanderPanda wrote:
| Same goes for car MMIs. Tesla is almost fine when it
| comes to the latency (still far behind an iPad e.g.) but
| other manufacturers are just atrocious in this respect
| HeyLaughingBoy wrote:
| The industry will do just fine. In all my years assisting
| in the hiring process (I'm software, but due to my EE
| background I was often asked to help with interviewing
| EEs), I've never noticed a shortage of EE applicants. OTOH,
| we had a lot of trouble finding enough software people to
| hire.
|
| The reality is that EE jobs are a small fraction of the
| software ones and supply is keeping up with demand, so
| there's no upward salary pressure.
| SteveMoody73 wrote:
| I design the majority of the electronics for my company and
| pretty much all the firmware as well.
|
| Wages are not bad for the area i'm in, which is fairly
| rural, but could be a lot better for the work involved.
| Move to a big city would probably help but I like the
| quieter lifestyle.
|
| I've not done any web development full time for close 20
| years, first started writing JSP code. Dabbled with a few
| personal website designs since then. I'm sure if I went
| back to web development, it may pay more but I don't think
| it would have the same level of job satisfaction for me. I
| try to keep up to date on some of the technologies used but
| it seems overwhelming from the outside.
|
| Part is resistence to change, but I do find the work for
| the most part enjoyable so it's a risk to change jobs as
| well.
| droopyEyelids wrote:
| The demand for EE roles is far less than the demand for
| Software roles.
|
| For a simple thought experiment, imagine if you could get a
| good developer for $20 an hour. Every single company on the
| planet, from a mom and pop shop to big corporations could
| turn a profit off their work.
|
| Now imagine you could get an electrical engineer for the
| same price. What percent of businesses could profit from
| electrical engineering? 2%?
| gryBrd1987 wrote:
| The context OP setup was "when grey beards retire."
|
| The ideas being demand is low as the senior EEs stay put.
|
| Mom and pop shops could use Excel and did successfully
| for years. Big banks even ran on gigabyte sized Excel
| sheets before the 2010s hype bubble (Source: direct
| experience working in fintech 2010-2015)
|
| Anyone in tech believing the last 10-15 years was about
| anything but the US government juicing its economy to
| stay relevant, titillate, and ingratiate itself on now
| 30-40 something college grads is fooling themselves. All
| those students are now bought in to keeping the dollar
| alive.
|
| Software has gotten so over thought and bloated given a
| "too many cooks in the kitchen." situation. Templating a
| git repo with appropriate dep files given mathematical
| constraints is not rocket science. The past needed to
| imagine software as out of this world to gain mindshare.
| Correct and stable electrical state is what really
| matters.
|
| We are entering a new era of tearing down the cloud
| monolith for open ML libs that put machines to work, not
| people.
|
| Behavioral economics has been running the US since before
| Reagan.
| Aromasin wrote:
| My point wasn't about demand though. I'm well aware it
| flags behind SW companies by a staggering margin. A small
| team of SE's with enough money to buy some laptops
| between them can create multi-million dollars worth of
| value in a few years. It would take a team of EEs 5x the
| time and 25x the initial investment to create the same.
| Of course there are going to be 100's of SE companies for
| every EE one.
|
| My comment was regarding supply. EE is an art that
| blossomed in the 80s and 90s in terms of practicing
| engineers, and has shrunk per capita since. This is
| largely driven by kids getting drawn into SWE over EE as
| people look at salaries and modern day billionaires, and
| figure it to be a no-brainer. Today EEs are a small
| fraction of the total engineering disciplines, despite
| being essential for the communication, power generation,
| distribution, consumer electronics, aerospace,
| automotive, and of course, the computer hardware industry
| on which the software one is built; amongst many other
| growing sectors like robotics, medical, and IoT.
|
| If there are a legion of EEs are set to retire in the
| next 5-10 years, and all the would-be EEs are now
| designing web apps, surely at some point the
| supply/demand scales start to tip one way? Many of the
| above industries are abstracting everything to software
| platforms as time goes on, but no amount of money can
| make a SW dev design a power-train for a car, antenna for
| a 5G device, or program an FPGA for silicon verification.
| HeyLaughingBoy wrote:
| Bear in mind, though, that a lot of those EEs going into
| software are doing so not because they love software, but
| _because they can 't find EE jobs_. Sure, many are no
| doubt doing it for the money, but if they really wanted
| to be programmers, they'd have majored in CS.
| metalforever wrote:
| Yeah same, I'm an EE camping out in software because of the
| pay. It's also just easier work. I would much rather be
| intellectually challenged coding firmware or embedded work.
| I didn't go to school to build web widgets. It's just EE
| pays so badly you can't make the bills. I was getting
| offered numbers that wouldn't have afforded my own studio
| apartment to rent. For EE work. It's insulting.
| riskable wrote:
| ...which is ridiculous because of what it takes to become
| an EE VS what it takes to become a "web developer".
| Basically anyone who can handle _basic logic_ can be a
| web developer if they just put in a bit of effort. Degree
| or not!
|
| To become an EE you _need_ a 4-year degree and a whole
| heck of a lot of knowledge about things that are a real
| pain in the ass for laypeople like calculating
| inductance, capacitance, and impedance ( <shudder>).
|
| You don't need much knowledge to make a circuit board,
| no. But when your boss wants to add a USB 3.0 hub to your
| product it suddenly becomes a, "wow, we really need an
| EE" job (because the spec has so many requirements and
| you're not going to get your product certified unless you
| can demonstrate that you followed it).
| robomartin wrote:
| > 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 designs these days can be
| done by people with very little EE education. Anyone can
| learn anything online. There are plenty of resources.
| This is a good thing, of course.
| riskable wrote:
| 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.
| robomartin wrote:
| > 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.
| josephg wrote:
| Honestly all of that sounds like it maps pretty well to
| programming.
|
| I sometimes run little 30 minute programming workshops
| where I teach people enough of the basics that they can
| walk away with something they've made. Give a novice 3
| months to go through an bootcamp and they can become a
| half useful programmer.
|
| But the "other half" of their knowledge will take a
| lifetime to learn. In just the last 2 weeks my job has
| involved: crypto algorithms, security threat modelling,
| distributed systems design, network protocols, binary
| serialisation, Async vs sync design choices, algorithmic
| optimization and CRDTs.
|
| It's easy enough to be a "good enough" programmer with a
| few months of study. But it takes a lifetime of work if
| you want to be an all terrain developer.
| riskable wrote:
| > Yet, such PCB's are trivial to design.
|
| No, analog keyboard PCBs are not trivial at all. You have
| to keep a lot of things in mind when routing your analog
| VS digital tracks. Especially if you've got per-key RGB
| LEDs right next to your hall effect sensors (can be a lot
| of noise if you don't do it right).
|
| Not only that but you also have to figure out how to get
| loads of analog sensors into a microcontroller that may
| only have 4 analog pins (e.g. RP2040). In a way that can
| be scanned fast enough for 1ms response times (again,
| without generating a ton of noise).
|
| It's not so simple like an electromechanical keyboard PCB
| which _is_ quite trivial.
|
| > 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.
|
| ...except 99% of all PCBs aren't that complicated. You
| don't need to know the specifics of RF in order to design
| a board that controls some LEDs.
| metalforever wrote:
| I don't really see why you would create a keyboard in
| this way.
|
| > ...except 99% of all PCBs aren't that complicated. You
| don't need to know the specifics of RF in order to design
| a board that controls some LEDs.
|
| There is a difference between creating something that
| works, which is easy enough to do, and creating something
| that is competitive on the consumer market, i.e. that
| BARELY works. This is the difference and why you would
| pay an EE to do this job.
| weatherlite wrote:
| > Basically anyone who can handle basic logic can be a
| web developer if they just put in a bit of effort. Degree
| or not!
|
| A "modern" web dev needs to know a whole bunch of crap
| nowadays. Not saying it's insanely hard but its not that
| easy. But sure, getting a job as a junior should be way
| easier than EE.
| synergy20 wrote:
| system programming is a tough and low reward path indeed, be
| it in c/c++ or whatever.
|
| embedded/EE is worse.
|
| unless you made into the big
| few(google,amazon,meta,apple,microsoft,...), salary will
| plummet by half in general, or even more.
| DeathArrow wrote:
| Well, I am happy I transitioned from C/C++ to backend. And
| frankly, I do like backend more.
| zabzonk wrote:
| c & c++ are backend languages, in my experience - what do
| you mean?
| DeathArrow wrote:
| I mean web backend, web apps, services, microservices.
| ostenning wrote:
| I have an EE background but worked in webdev for many
| years. I got pretty bored with webdev, and had the
| opportunity to get into embedded Rust development, so I
| did. Its been really awesome, learnt so much both in
| embedded but also hardware engineering.
|
| But now I think I'll head back to web development for my
| next job - I think web is better as an employee or as a
| contractor. It seems to me there is more freedom in webdev,
| often its possible to work from home or abroad... Embedded
| on the other hand is encumbered with equipment,
| oscilloscopes, devboards, protocol analyizers, you name it
| and often requires onsite hours.
|
| And then there is the pay and job availability... I recall
| interviewing for a role that involved designing a full-
| blown operating system for use in the auto-industry. The
| role was paying 40-50K euro a year in Germany, which is
| insanely low. React developers earn substantially more, but
| are required to know substantially less.
|
| The only reason why (I can imagine) someone would chose
| embedded is probably because its very rewarding and
| mentally stimulating. Its awesome creating physical
| devices. Its awesome interfacing with the real world. Its
| awesome deep diving into bootloaders, memory allocations
| and exercising a fundamental understanding of computing.
| sentinalien wrote:
| This is true, trying to switch from FPGA's/RTL Design to
| something higher up the stack over the next few months for
| this reason. My employer does seem to have great difficulty
| hiring anyone with these skillsets but funnily enough, the
| salaries never seem to improve.
| cmrdporcupine wrote:
| This is what I find astounding.
|
| I wonder how much is just EEs looking at SWE resumes and
| going _" why would I pay that much for this?! writing
| code isn't that hard"_ I definitely get that vibe from
| some of the local hw-eng companies.
|
| And they may not be wrong, but.. sorry, that's supply and
| demand. If I have to go write stupid NodeJS stuff to get
| paid decently, I guess I'll have to go do that.
| larve wrote:
| 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 possible is that the EE had a
| MIT degree, while I'm self-taught, and that we had always
| delivered our firmwares on time and without bugs.
| cmrdporcupine wrote:
| I mean, it's the same phenomenon I've seen even in webdev
| where a PM or UX person who has produced a whole series
| of mocks then hands it off to the "programmers" and
| demands a short schedule because... well... they did all
| the hard stuff, right? You're just making it "go."
|
| People naturally see their own hard work and skills as
| primary. I know enough about HW Eng and EE to know that
| it's actually really hard. That said, it doesn't have the
| same _kind_ of emergent complexity problems that software
| has. Not to say that HW eng doesn 't have such problems,
| but they're a different kind.
|
| If you see the product as "the board", then the stuff
| that runs on the board, that can end up just seeming
| ancillary.
|
| Very frustrating, for sure.
| alxlaz wrote:
| 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
| that ever happened to engineering education. Back in
| college I had to save money for months to buy an entry-
| level development kit. But it made the non-technical part
| of my job exponentially harder.
| HeyLaughingBoy wrote:
| 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]
| jack_h wrote:
| I worked at a place once where one of the EEs who wrote
| firmware told me that algorithms and data structures were
| pointless because in the end it's just bits in a linear
| address space in RAM.
|
| The industry has basically screwed itself. It's pretty
| typical for companies to consider embedded/firmware as EE
| work that is done in the gaps of the hardware schedule.
| EEs generally make bad programmers which shouldn't be a
| surprise as their background is usually not in software
| development; I similarly shouldn't be hired to do EE
| work. Because of this the code bases tend to be abysmal
| in quality.
|
| The salary for these positions tends to be tied to EE
| salaries which for some reason are quite low. So it's
| hard to attract good talent willing to deal with the
| extremely poor code quality and all of the other extra
| challenges this field has on top of normal software
| challenges.
|
| Since few software developers are attracted to this niche
| there's not a lot in terms of libraries or frameworks
| either, at least not in comparison to most other software
| ecosystems. I've had a start-up idea for a while now to
| really close that gap and make embedded development far
| more sane in terms of feature development and such, but I
| worry nobody would even bother to use it.
|
| I've been in the embedded space for years now and I've
| been considering bailing because the problems just aren't
| worth the pay.
| reachableceo wrote:
| I'm interested in your startup idea .
|
| I'm needing todo some highly complex embedded development
| for my startup in a highly regulated safety critical
| space.
| robomartin wrote:
| > one of the EEs who wrote firmware told me that
| algorithms and data structures were pointless because in
| the end it's just bits in a linear address space in RAM.
|
| This is, of course, wrong. However, I think I understand
| where this EE was coming from.
|
| At the end of the day, once all is said and done, there's
| a minimal set of instructions necessary for a CPU to
| perform any task. One could add to that two more
| variables: minimum time and minimum resources (which is
| generally understood to be memory).
|
| So, at least three optimization vectors: instructions,
| time and resources.
|
| Today's bloated software, where everything is layers upon
| layers of object-oriented code, truly is pointless from
| the perspective of a CPU solving a problem along a stated
| combination of the three vectors listed above.
|
| The way I think of this is: OO exists to make the
| programmer's life easier, not because it is necessary.
|
| I believe this statement to be 100% correct. OO isn't a
| requirement for solving any computational problem at all.
|
| Of course, this cannot be extended to algorithms. That
| part of the EE's is likely indefensible.
|
| How about data structures?
|
| Some, I'd say. Again, if the data structure exists only
| to make it easier for the programmer, one could argue it
| being unnecessary or, at the very least, perhaps not
| optimal from the perspective of the three optimization
| vectors.
| analognoise wrote:
| Oh my god this is me.
|
| I'm not sure what to do, but I'm trying to get the hell
| out.
| lamontcg wrote:
| > Working fulltime in Rust now, but it's hard to find work
| there that isn't crypto-tainted.
|
| There's a whole bunch of ex-C++ devs who have shifted to Rust
| in this thread.
|
| The existing C++ jobs probably need to shift to Rust.
| dataking wrote:
| Immunant offers no-crypto remote Rust work. Send resume to
| team@immunant.com
| jcelerier wrote:
| > Yes, the embedded space pays terrible, and the employers
| don't seem great on the whole.
|
| in europe c++ pay is in general ridiculously bad, I got some
| job ads this morning. Senior job in real-time trading in C++
| in Paris, multithreading and linux knowledge, english first:
| 55-75k. Embedded senior C++ FPGA engineer in paris: 45k-65k.
| No bonus in either position. thanks but no thanks
| DeathArrow wrote:
| I make 54k net in Romania working as a backend developer.
| If I move to France and use C++ my living standard would
| take a hit. :D
| danuker wrote:
| > crypto-tainted
|
| If the government did its job and we had sound money, and
| taxation were explicit instead of this wacky adjustable-and-
| unpredictable-devaluation that is inflation, there would be
| no need for cryptocurrency.
| three_seagrass wrote:
| I don't know why you say that, because even in lieu of high
| inflation, USD has been less volatility than the majority
| of cryptocurrencies.
| jmnicolas wrote:
| With fiat you KNOW you're getting poorer by the minute,
| but with crypto you have the hope you will earn more.
|
| Fwiw I have a grand total of 300EUR "invested" (or "lost"
| if you're a pessimist) in crypto, so I'm not exactly a
| crypto fanatic.
| sqeaky wrote:
| 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 spree.
|
| After the work was done, they shed nearly all the contractors
| and about half of their previous full time employees. Just
| quadrupled their staff to make a voting machine then fired
| them all.
|
| They hired me as an "Embedded Software" on their Firmware
| team. It was a total shitshow we didn't have unit tests or
| CI. The new hires insisted on it and I spent a bunch of time
| maintaining a Jenkins setup for the team that really helped.
|
| The pay wasn't great, a little less than defense contracting,
| which was a little less than insurance companies and slow
| finance companies.
|
| If that is what most embedded development is like then I see
| why it is brings the average down.
| ronanyeah wrote:
| > They make a significant portion of all US voting
| machines.
|
| > Just quadrupled their staff to make a voting machine then
| fired them all.
|
| Fascinating.
| sqeaky wrote:
| 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.
| [deleted]
| bombolo wrote:
| Ah yes I used to work at a california company as c++
| developer.
|
| There was no automated test whatsoever. QA department was
| just manually clicking things on a client that would
| connect to my c++ thing.
|
| When I wrote a couple of unit tests I got told off because
| I was wasting time not doing features.
| jahewson wrote:
| Why waste time writing tests when you could be busy
| fixing bugs!?
| theironhammer wrote:
| Best comment ever!
| ornornor wrote:
| So that's what they teach in MBAs!
| Remnant44 wrote:
| Jokes on you, they probably didn't fix big either ;)
| sqeaky wrote:
| When was that? I am so glad that for the past 5~6 years
| every contract I have worked has had unit tests and for
| the past 10~12 every place has at least accepted their
| value.
|
| The last time I actually had to argue for unit tests was
| in defense contracting and not for the team I was working
| on. Some idiot at a lunch-and-learn community thing tried
| to claim there was no short term gain from them and we
| had defined short term in months. He could not believe
| that unit tests can help the developer writing them and
| the help the team the very next sprint.
|
| I hope he learned better or got forced out of tech.
| galangalalgol wrote:
| I have worked on codebases where full coverage was
| obtained using service level tests in a proper pipeline.
| If you couldn't add a service level test that got your pr
| coverage, then you were referred to yagni and told to
| stop doing stuff that wasn't part of your task. I was ok
| with that, it worked well, and the tests were both easier
| and faster to write. If the services had been too large
| maybe it would have fallen apart?
|
| I have also worked on codebases where there were only
| tests at the level of collections of services. Those took
| too long to run to be useful. I want to push and see if I
| broke anything, not wait hours and hours. If a full
| system level test could complete in a few minutes I think
| I would be fine with that too. The key is checking your
| coverage to know you are testing stuff, and to write
| tests that matter. Coverage can be an antimetric.
| sqeaky wrote:
| > I have worked on codebases where full coverage was
| obtained using service level tests in a proper pipeline.
|
| Sounds ideal to me. Add testing where it is cheap enough
| to justify, and maybe just a little more than you think
| you really need because they pay off so often.
|
| If your mocks and fixtures get too big you might not be
| testing the code in question meaningfully.
|
| Coverage and test quality/quantity need to scale with the
| associated risk. Perhaps "Flight planner for Air Force
| Weather" gets more testing than "Video game User
| Interface" and that's ok. Even in gaming, the engine team
| should have more tests than the game teams.
| DeathArrow wrote:
| If there are no unit tests, you can intentionally
| introduce some bugs, so you can have some easy fixes next
| sprint. Rinse and repeat.
| cmrdporcupine wrote:
| Sadly this sounds like a lot of crappy software shops
| generally, embedded or not.
| filoleg wrote:
| Yeah, but in real life scenarios, the difference in
| actual numbers, as opposed to percentages, matters.
|
| Let's imagine that the split for all software shops is
| 80/20, with 80% being crappy, and 20% being decent. If
| there are 10 embedded software shops out there, it means
| there are only 2 decent embedded shops out there that an
| engineer can work at. Meanwhile, if there are 1000 non-
| embedded software shops, it means that there are 200
| decent shops an engineer can work at.
|
| This creates a wild disparity, even if the ratio of
| crappy to decent is exactly the same for all software
| shops in general.
| trap_goes_hot wrote:
| In real-life, engineers aren't just cogs in a wheel that
| are interchangeable, who can seek work in any
| organization. There is also a smaller number of people
| who can/want to do systems level/embedded programming.
| filoleg wrote:
| Yes, I agree with you. Which is why I explained that
| despite the overall ratio of crappy/decent shops might be
| the same for all software work areas, embedded devs are
| the ones who get the short straw.
| gridspy wrote:
| To build on your argument:
|
| The 20% decent shops are retaining their engineers and
| only growing at a sustainable rate. Available new jobs
| are filled with a referral since every employee is
| constantly bragging to their friends. So they post few /
| no new jobs online.
|
| The 80% crappy shops are shedding employees (turnover)
| and also poorly managed so they fire everyone and rehire
| later. Only the worst employees decide to remain during
| such a purge. So most new posted jobs (more than 80%) are
| for such companies.
|
| Then the 80% crappy companies talk about their issues
| finding staff and you get articles complaining how hard
| it is to find XYZ employees (interns, C++, even
| supermarket staff). But the real problem is the company
| in question, not the industry as a whole.
| azinman2 wrote:
| Sounds... problematic. What can you say about the state of
| security with it?
| sqeaky wrote:
| 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.
| speeder wrote:
| I am from Brazil. If you saw the news, the current
| president that just lost elections, been insisting for
| years, that elections here are untrustworthy.
|
| Reason is simple: electronic voting machines with no
| logging, paper trail or anything. And the common people
| doesn't have permission to do penetration tests or read
| the entire source. All of it is proprietary and secretive
| with no public testing basically.
|
| For years the now president, when he was still
| congressman, been trying to make a law where the voting
| machines will print the vote, and deposit on a box. This
| way people can count the votes printed not just trust the
| machine, but the government keep inventing reasons to not
| allow this, even when a law passed, judiciary struck it
| down.
|
| Thus today people are protesting, seemly almost half of
| the country voted for him, the difference was tiny, they
| are protesting. The winner insists elections were fair,
| but how you prove it when the machines are proprietary
| and secret? How you prove it when they have no log of
| votes, and instead just print the totals? In a country
| full of corruption, and where the the mafia literally
| made a party to commemorate a specific person became
| chief election judge, how you trust nobody bribed the
| manufacturer or the programmers?
| sqeaky wrote:
| Most American voting machines print a ballot an let the
| voter review it, but not all. There have been some
| jurisdictions that have given up on that for reasons that
| seem bad and vague to me.
|
| I think mandating that voting machines be open source is
| a good idea to me. Here in the US we have 3rd party
| auditing companies. Various US State and the Federal
| Government all have different testing/auditing labs that
| they have certified they trust. Then each voting machine
| company has to convince them that it is good to sell to
| the governments that trust them. The final build that the
| lab signs off on gets a cryptographic signature and the
| poll workers are supposed to check that it matches what
| they are given to run on their machines just before the
| setup their machines for voting.
|
| Do Brazil have anything similar with auditors or
| inspectors? Or at least some crypto connecting the vendor
| to the polling locations?
| josephg wrote:
| This is really interesting. Here in Australia we still
| use paper ballets for the lower house of parliament. I
| volunteered as a "scrutineer" for one of the parties,
| which let me go into the warehouse where the ballots were
| being counted and watch. As an scrutineer, you physically
| look over the shoulder of the person counting votes and
| double check their work. You can't touch anything, but if
| you disagree with the vote, you can flag it. The voting
| slip gets physically sent to a committee somewhere for
| final judgement.
|
| I highly recommend the experience if you're Australian -
| it was very cool seeing democracy in action. I personally
| have a lot more faith in our system of voting after
| seeing it in action first hand.
|
| That said, the senate votes are all typed into a computer
| by the election officials. It's just too hard to do
| preferential voting by hand with ~200 candidates on the
| ballot.
| agumonkey wrote:
| 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 ?
| cmrdporcupine wrote:
| There's a strike happening here in Ontario schools by
| janitors and education assistants and early childhood
| educators, because they want more than a 2% raise on their
| $40-$50k year jobs ($30k USD, and look at inflation #s...).
| The government is going to use a special "shouldn't be
| used" clause in the Canadian charter or rights and freedoms
| to force a contract on them and ban a strike and forbid
| collective bargaining despite it being a charter right.
| These are people who clean poop, shape young minds, and
| keep critical systems running, and so on.
|
| All of this to say: difficulty and importance of a job
| seems to have almost nothing to do with either the pay one
| gets, or the respect one gets.
| agumonkey wrote:
| I understand but you'd think it wouldn't affect people
| with "high skills and diplomas" the same as a janitor.
| marcosdumay wrote:
| It's a sign that people inherently want to work on those
| hard problems.
| agumonkey wrote:
| I interpreted it as 'the market only cares about frontend
| sexiness'
| marcosdumay wrote:
| Well, it's a sign that the people hiring developers and
| the developers want different things.
|
| That saying that the client is always right exists for a
| reason.
| HeyLaughingBoy wrote:
| 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.
| MontyCarloHall wrote:
| >EE salaries are sadly lower than they rightfully should be.
|
| Profit margins of an EE will almost always be lower than
| profit margins of a software engineer. A team of software
| engineers can quickly scale to selling to millions of users
| (and collect nearly 100% of the resulting revenue as pure
| profit), whereas a team of EE's cannot a) scale their
| customer base as quickly, since scaling up manufacturing
| takes time and b) realize a profit anywhere close to 100% of
| revenue, since much of their revenue goes towards
| manufacturing and distribution costs.
|
| In other words, the marginal cost of selling one unit of a
| physical product is always nonzero, whereas the marginal cost
| of selling one unit of software is often (very close to)
| zero. That differential goes towards higher salaries for the
| software engineer.
| sentinalien wrote:
| I understand this but I think the biggest driver for
| software salaries is the sheer number of companies that are
| interested in hiring software engineers. Plenty of hardware
| companies are very profitable but do not raise their
| salaries because there is no market pressure to do so as
| the more limited job market means EEs/embedded engineers do
| not switch companies nearly as frequently and switching
| companies is generally the best way to get a substantial
| salary increase.
| KptMarchewa wrote:
| Yeah. For giant majority of applications and compankes
| the hardware exists already. Servers, phones and personal
| computers.
| adrianN wrote:
| Which hardware companies have SaaS margins? I think 10%
| margin is very good for a hardware company. A software
| company would aim for multiple times that.
| VLM wrote:
| In the long run, yes.
|
| There are shorter term effect where for at least a
| generation there's been too many new grads able to design
| hardware I2C devices, resulting in too many new grads also
| able to write I2C driver software as a backup career,
| resulting in low pay across the board for both fields.
|
| Just because a student likes the field, and can pass the
| ever more difficult filter classes along the way, doesn't
| mean there's a job waiting after graduation in that field.
| For some reason students keep signing up for an EE
| education even though the odds of them getting an EE job
| after graduation are very low. The odds of them getting any
| job, even a high paying one, are good because the majority
| of the graduating class goes into software development,
| mostly embedded, but most kids who can, like, bias a
| class-C amplifier transistor, will never have a job doing
| EE stuff, there's just too many EE grads for too few EE
| jobs.
|
| As another example of that effect, see also K-12 education
| where for at least one generation, the bottom half of the
| graduating class was never employed in the field, at least
| in my state. Enrollment for K12 has absolutely cratered in
| recent years, and now most grads have a reasonable chance
| of getting a job in their field.
| antegamisou wrote:
| You may also look into Kernel Programming for a lucrative
| systems programming career. It is more C and low-level
| oriented though.
| deaddabe wrote:
| > You may also look into Kernel Programming for a lucrative
| systems programming career.
|
| This is the road I have taken since I started to work
| professionally, but I yet have to find a lucrative job. I
| know that I am paid more than microcontroller devs, but
| less than web devs. The market for kernel developers is not
| that big either.
| boredtofears wrote:
| That's insane to me... getting into systems programming
| recently I am well aware of how much harder it is than
| web dev.
| larve wrote:
| I've been in both web and embedded for the last 20 years,
| and to me web dev "done right" is just as much if not
| more complicated than embedded, and very similar. In both
| cases, you have a distributed systems (everything action
| you take, system wise, is asynchronous, and very
| uncertain). Debugging is a pain in both cases, because
| you have only limited access to the system under test
| (especially in the field), and things like minification /
| optimizing compilers make it hard to necessarily track
| bugs.
|
| Embedded has the advantage that you can usually trust
| your peripherals more (they're not a user that randomly
| presses CTRL-R), there is less framework and thirdparty
| stuff in your way, and the timing constraints are usually
| better understood. Webdev also suffers from a ton of UX
| and UI (animations, wizards, complicated workflows, error
| handling that needs to be error handled that needs to be
| error handled), which often results in very complex state
| machines.
|
| In both cases, observability is key, especially for
| debugging purposes. I use the same patterns in both
| cases: a lot of state machines and event driven design,
| because I get "debugging" for free (I just need to log
| state + events and I can reproduce any scenario).
|
| The big advantage of web, and one that I always have to
| adjust to when I come back from a period of time in
| embedded, is that you can YOLO a lot. YOLO to prod, you
| can always easily revert. YOLO the UI, because you can
| trust the user to refresh their page or workaround it
| (your hardware peripheral won't). YOLO everything because
| you'll never really brick stuff. YOLO timing because you
| usually don't have hard or even squishy-hard realtime
| requirements. YOLO behaviour because you can have
| realtime feedback on how your system is doing, and
| pushing a new version is only minutes away.
|
| But "web dev" done right, and I really like having
| something fast, robust, repeatable and observable, is
| quite the challenge too.
| larve wrote:
| I realize I mostly focused on the frontend side here, but
| you can easily see how backend dev is highly complex too
| (but that often falls under system programming too).
|
| Lots of framework, in fact most of the runtime
| environment is not under your control _at all_ (cloud
| services, for example). Complicated deployment and
| distributed patterns, often requiring many services to
| collaborate for a single functionality (DB, monitoring,
| cache, load balancing, backend itself, storage in just
| the simpler cases!). And none of this is something you
| can just plug your debugger into and hack away at it.
| Very similar to embedded in how I approach it.
|
| Deployment is similar too, in that you will often have a
| builder system that creates artifacts than then get
| deployed asynchronously, resulting in heterogeneous
| environments at least for a while, with needs for proper
| API boundary design.
|
| Seeing the parallels between both worlds allowed me to
| use CICD, blue/green, feature flags, data pipelines to
| the cloud, UI patterns from the then nascent javascript
| framework explosion back in the late aughts, when that
| stuff was almost unheard of in embedded environments. I
| scripted my jtag environment using rhino (javascript on
| the server, back before node came out) to collect and hot
| reload pieces of code, while being controlled in the
| browser. I made a firmware app store for midi controllers
| I was building.
|
| Embedded UIs also highly benefit from knowing patterns
| from web frontend, because they are highly event based
| too, and really benefit from attention to detail (say,
| animations, error handling, quick responsiveness). At any
| point the user interacts with the device, through a
| button, a touchscreen, a sensor, UI feedback should be
| immediate and obvious (even if it's just a LED turning
| on). Good web applications are absolutely amazing in how
| they achieve that (through CSS, through JS, with nice
| layout / graphical design patterns).
|
| I think it really pays off to do both.
| selimnairb wrote:
| Harder yes, but at least you don't have to keep up with
| "flavor of the month" frameworks and toolkits that
| frequently change.
| DeathArrow wrote:
| I did embedded and now I do backend. I wouldn't say one
| is harder than other. Things are very different.
| yxhuvud wrote:
| Payment is not based on hardness, it is based on demand
| and supply.
| AndriyKunitsyn wrote:
| Not only on hardness, but hardness influences how much of
| supply of competent workers the market has.
| eulers_secret wrote:
| I did Linux kernel work for a decade at my old company.
| Left due to low pay.
|
| Also worried about my employability. Not much call for C
| programmers in 2022. You'll always fear losing your job.
|
| I love low level though, I do embedded projects for fun!
| I can probably sling back-end Python for 1.5x the salary.
| I wish embedded payed better, but it doesn't and
| therefore I won't help alleviate this "shortage".
| [deleted]
| anonymousDan wrote:
| Interesting, what types of companies pay well for kernel
| programming?
| antegamisou wrote:
| I remember Apple having a lot of related listings so I'd
| assume companies that are somehow involved in OS
| development (Microsoft, Google, maybe RedHat/IBM and
| Intel).
| caskstrength wrote:
| Significant portion of kernel code is written by FAANG,
| for example. There are other companies that also pay
| reasonably well. You can check some statistics of
| contributions to Linux kernel here
| https://lwn.net/Articles/909625/
| synergy20 wrote:
| not many, I did it, jobs are scarce, most of the time you
| port a new version of CPU to the kernel, or add a few
| device drivers, the industry does not need a lot of those
| engineers, and per my experience, not compensated that
| well either. these days many kernel programmers work for
| big companies.
| maldev wrote:
| Alot of government and security researcher jobs pay
| google tier for kernel skills with strong knowledge of
| the OS.
| 0x0203 wrote:
| Defense industry has a few such jobs, working a lot with
| RTOS's, network devices, sometimes even embedded for
| signal processing/control systems, etc... The big defense
| contractors probably pay better than working directly for
| the govt depending on where you live.
| wutbrodo wrote:
| I feel almost exactly the same way as you. I've flitted
| around the research/applied research boundary for ML for the
| last decade+, so I write plenty of Python. I enjoy the way
| Python gets out of my way so I can focus on interesting
| research problems. But the actual act of writing code in C++
| is so much more _fun_ , once you get good enough at it that
| the footguns don't trip you up.
|
| The embedded AI space is a pretty good place to make money
| writing C++. I was in autonomous vehicles for a bit. It
| didn't really interrupt my post-Google compensation
| trajectory, and I got to write performance- and safety-
| critical C++
| npigrounet wrote:
| NegativeLatency wrote:
| My local bus/transit agency was hiring an embedded programmer
| a couple of years ago and while I thought it would be fun to
| do embedded stuff and get to work on busses/trains (!) the
| pay was like half my web dev salary. (Granted there is a
| pension but it's not that good)
| lazypenguin wrote:
| 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?
| DeathArrow wrote:
| >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.
| kevstev wrote:
| 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.
| lazypenguin wrote:
| Why would you dismiss my comment on my presumed experience?
| Seems a bit arrogant. Did I say all backend problems are
| easier or that all C++ problems are harder? No, I merely
| stated why work on hard C++ problems for less pay when one
| can work on easier backend problems for more pay.
| scruple wrote:
| I left embedded for web about a decade ago and doubled my
| salary overnight while taking on a role that was less
| demanding. My experience from embedded gave me an advantage
| over colleagues, specifically with regards to troubleshooting
| systems and performance problems, (edit) and the ability to
| read / understand the C/C++ code that so many of these
| languages, their standard libraries, their extensions, etc.,
| are implemented in, that has carried forward to this day.
|
| I'd love to go back to embedded but I can't cut my salary in
| half to do it.
| intelVISA wrote:
| The life hack here is to pick up a handful of web jobs and keep
| C++ for leisure.
| the_only_law wrote:
| And it seems like most of the jobs in the domains where C++ is
| common want established domain experts and maybe a handful of
| new people coming in through university pipelines.
| tyingq wrote:
| I would guess Microsoft's push for C#/.Net is affecting this as
| well.
| Gibbon1 wrote:
| There are a lot of projects written in
| C++/Python/NodeJS/Go/Ruby that really should be written in
| C#/.net.
| onlyrealcuzzo wrote:
| > Because Python pays more.
|
| In the extremely underpaid start-up world?
|
| C, Java, C++, Kotlin, Swift, etc - IIUC pay MUCH better and are
| more in demand at companies where you _really_ make good money
| as an engineer.
| goalieca wrote:
| In the past few years I've discussed salaries with dozens of
| companies as a staff level IC. C++ companies pay
| significantly less even if the work is far more specialized
| and challenging. The real money is in "Cloud +
| python/golang".
| onlyrealcuzzo wrote:
| Dozens of highly profitable public tech companies?
|
| There's really on APPL, GOOG, MSFT, AMZN, FB.
|
| Pinterest, AirBNB, Adobe, Intuit, Snap, Roblox, etc are
| usually a pretty big drop in pay - but usually above all
| but the highest of high paying startups.
|
| The vast majority of actual cloud jobs - building cloud
| infrastructure - are low-level - not Python.
|
| Are you talking about startups using AWS? I'm not sure
| that's a "cloud" job.
| DeathArrow wrote:
| Not according to latest developer survey by Stack Overflow.
| melony wrote:
| 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.
| synergy20 wrote:
| I'm also surprised c++ is paid less than python and javascript
| these days, embedded c/c++ jobs are also paid less which
| requires years of experience to get better at.
| bluetomcat wrote:
| C++ shops are a diverse beast. There's the legacy MFC desktop
| app from 1999 dentists are using to upload dental imagery,
| there are high-profile Windows applications and games, there
| are also cutting-edge ML, computer vision and simulation-
| related domains.
| bsder wrote:
| > Employees may be leaving the embedded space (and C++) for web
| tech because of this.
|
| It's remote work.
|
| Remote work is basically forcing _ALL_ software shops to pay
| more money. If you 're smart enough to program C++, you can
| program _ANYTHING_.
|
| Let's stop calling it a labor shortage and call it what it
| really is--a salary shortage.
| galangalalgol wrote:
| Yeah, but it is kind of unique in that the skillset is in
| demand for two different types of business, and one has a
| drastically higher profitability and demand for people. That
| by itself isn't that unique, there are any number of jobs
| that don't exist because the qualifications would make
| employees too expensive. But we actually rely on this stuff
| for our modern world, we need these jobs to exist, but we
| won't pay for it, so you only get those who love the work,
| and those who are too bad to do anything else. So far, that
| has been enough. Teachers, Nurses, and Vets are similar, so I
| don't guess it really is that unique. And we are seeing
| shortages in all of those too.
| diego_moita wrote:
| No, the pool isn't running dry.
|
| Pay me more and I'll go back to C++.
|
| For the same salary I'll stay with Rust.
| skhameneh wrote:
| I'm surprised to not see any comments mentioning Rust and Go.
| (Rust is mentioned in the article)
|
| Go intends to bring better team efficiency without giving up much
| performance. Rust intends to bring safety with similar
| performance to C++.
|
| There's mentions of Python (and some others) in comments, but
| those language stray a bit too far from being useful as general
| purpose languages where C++ has been used historically (but
| that's not too say there aren't efforts to use Python/Cython
| embedded).
| eqvinox wrote:
| My impression always was that the problem with C++ is the high
| skill/brain cost in relation to usable ability payoff... which
| makes a limited talent pool a logical consequence.
|
| (What I mean by that is -- comparatively speaking, C++ has a much
| larger set of things that you need to know, understand, and apply
| correctly to get the same kind of thing done relative to other
| languages.)
| pclmulqdq wrote:
| It's not that the pool is running dry, it's that they're burning
| through the pool. Places like banks and most hedge funds are
| usually really bad to work for, and they aren't paying that well
| compared to FAANGs and unicorns (who they are competing with for
| talent). The exception is _a few_ of the HFTs: they can have good
| engineering-focused cultures, but you will still work 50 hours
| per week or more.
|
| These companies are _more selective_ about who they hire than FB,
| Netflix, or Google, and almost universally, the talent they want
| is having them bid against very high-paying tech companies.
|
| The last few times I spoke to a recruiter, I asked for salaries
| over $500k because that would make it worth it to go there
| instead of staying at Google - I was making more than half that
| at G, and working 20-30 hours a week. Most of them said that they
| would not offer near that. The ones that would wanted me to be
| the next coming of Bjarne (in terms of C++ knowledge) to pay that
| rate. They were hiring a lot of people from defense contractors
| at the time.
|
| Anecdotally, a lot of developers who enter one of those firms
| early and stay tend to get to the $500k-1M range pretty easily,
| but they seem to be a lot less willing to hire in that range.
| Comparatively, Google and Meta are happy to make $400k+ offers.
| bogwog wrote:
| Question: what kind of skills do financial companies typically
| look for from C++ devs?
|
| Whenever I hear "C++ expert", I don't know what that means. Are
| they masters of the STL? Are they part of the "C with classes"
| church? Are they an unhinged template meta programmer? Are they a
| major gcc/clang contributor? Did they co-author a part of the
| language spec?
|
| Or are they just some dude with 7 years of experience working on
| a single C++ codebase and the subset of features that happens to
| be using?
| twic wrote:
| More specifically in trading, the most important thing seems to
| be to know how to write fast code, while keeping the codebase
| maintainable, because it's going to keep growing, and will need
| to change as the world changes.
|
| That means avoiding polymorphism (and so a fair chunk of OO
| design), making heavy use of templates, and understanding the
| performance characteristics of language constructs and standard
| library functions. Expect to be slinging godbolts back and
| forth, benchmarking obscure hashmap implementations, and
| occasionally sweating over the precise layout of structs to
| maximise their cache-friendliness.
| posnet wrote:
| From my experience in HFT, the answer was "unhinged template
| meta programmer" with a healthy dose of assembly/reverse
| engineering thrown in.
| inetknght wrote:
| As a talented C++ developer... yes there is a dearth of talented
| C++ developers.
|
| I've been to several C++ conferences. Even there, many of the
| engineers end up learning "new" things that are IMO basic
| concepts that have been around for years.
|
| I recently went through a hiring phase for Senior C++ engineers
| and most of the applicants were familiar with old tech. It was
| really disheartening to me to realize how many "senior" C++
| engineers weren't senior in real C++ experience. Even one of the
| hires ended up using a C style array in their first commit
| instead of std::array.
|
| It's really frustrating and makes me wonder if perhaps I'm in the
| wrong job: maybe I shouldn't be a _software engineer_ , maybe I
| should be a _software educator_ to teach modern concepts and _un-
| teach_ ancient concepts. Indeed, a lot of the ancient concepts
| directly contribute to the modern world 's problem of software
| safety.
| brnt wrote:
| > C style array in their first commit instead of std::array.
|
| In my neck of the C++ woods, neither are a good choice. My
| point is: C++ is not a language, it is a language group.
|
| Most north Europeans speak a Germanic language, which have many
| shared features and often partially shared dictionaries, yet
| they mostly won't understand each other without some further
| study. As a Dutch speaker I can't judge the quality of
| somebody's German, even though it sometimes feels like I should
| be able to.
| inetknght wrote:
| > _In my neck of the C++ woods, neither are a good choice._
|
| Just off the top of my head: "it's not resizeable" (use a
| std::vector instead) or "it's allocated on the stack instead
| of the heap" (you can use a std::unique_ptr<std::array> to
| put it on the heap). But what are the reasons to not use
| `std::array` in your neck of the C++ woods?
|
| > _I can 't judge the quality of somebody's German, even
| though it sometimes feels like I should be able to._
|
| The cool part about software languages is that they're
| implementations of data structures and algorithms.
| Understanding those gets you most of the way to understanding
| what the code does regardless of whatever native language is
| spoken.
| flohofwoe wrote:
| That's the problem with the C++ ecosystem, it is actually many
| vastly different ecosystems mashed together. It's impossible to
| find a "C++ developer" because there is no agreed upon "one C++
| style". It seems what you're looking for is a "C++ developer
| who likes to write the same C++ style as myself" ;)
| inetknght wrote:
| > _It seems what you 're looking for is a "C++ developer who
| likes to write the same C++ style as myself" ;)_
|
| No, I'm perfectly content with someone writing C++ in a
| different style.
|
| What I'm not content with is someone who uses old code
| without a technical reason why. C style arrays, for example,
| are 100% inferior to std::array. Old loops with indices are
| maybe 80% (off the cuff guesstimate) inferior to ranged-for.
| There's absolutely no reason whatsoever to use `delete` in
| any C++ code that doesn't directly handle allocations (and
| so, very esoteric), and simlarly for `new`. But I keep seeing
| these things (and many other examples) show up in newly-
| written C++ code from "experienced" developers. Maybe 90% of
| the time they'll fix their code when I point out the modern
| solution and what problems the modern solution solves, and
| the last 10% of the time ends up in a technical argument
| about the merit of the old code (and that's fine as long as
| there is a _technical_ merit for it).
| xtracto wrote:
| holy mother of god! I used C++ around 2000 for some old
| projects. When new and delete where the object oriented
| "equivalent" for malloc() and free(). So, if you don't use
| that, what do you use in 2022 C++?
| marcosdumay wrote:
| By the GP's opinion, you use the stl classes that
| implement RAII for you.
|
| What is, obviously, only one way to do it, with its up
| and downsides. Granted that the upsides are much more
| numerous than the downsides, but there is a reason it's
| not the only option available.
| inetknght wrote:
| `std::make_unique()`, `std::make_shared()`, or another
| function that wraps `new` and `delete` into an RAII type
| (commonly called a smart pointer) so that you, the
| developer, worry less about explicit memory management.
|
| And the standard smart pointers are perfectly extensible
| enough to wrap things allocated from C libraries (I like
| to pick on opengl's glalloc() and glfree(), though
| malloc() and free() are acceptable to pick on too),
| C-style `FILE` pointers, or even memory-mapped things
| from `mmap()`
|
| I would also point out that even in 2000, `std::auto_ptr`
| existed. So even in 2000 you probably should _not_ have
| been using `new` and `delete`.
| IX-103 wrote:
| std::auto_ptr was broken and didn't work with STL. It
| wasn't until C++11 introduced "move" semantics that you
| could really use smart pointers.
|
| You can't really blame him for not using a part of the
| language that was unusable, right?
| sqeaky wrote:
| Last time I needed to write `delete` I was either fixing
| some low level garbage code that was super old or writing a
| smart pointer for a case not handled by the standard
| library. Either way it was so long ago that I really can't
| remember which.
|
| Complaints about delete aren't about part of common modern
| C++, if they aren't from subject matter experts aren't well
| structured complaints.
| wnoise wrote:
| Last time you needed to, sure. The problem is that if you
| find out how to do dynamic memory allocation, there will
| be tons of resources pointing at new/delete. Parts of the
| language that all the experts agree are terrible are just
| sitting there, poking out behind a shiny facade, waiting
| to scratch the unwary.
| flohofwoe wrote:
| > C style arrays, for example, are 100% inferior to
| std::array.
|
| Are the advantages of std::array over C arrays big enough
| to add 8kloc to each compilation unit though?
| (https://www.godbolt.org/z/8noTndhcv)
|
| A range-checked std::array replacement can probably be
| written in a few dozen lines of code.
|
| That's the problem with all C++ stdlib headers, they are
| incredibly overengineered for what they bring to the table.
| vips7L wrote:
| I've had the same experience in Java. Experienced engineers
| that are learning "new" Java even though those features came
| out years ago. I really think this will be the case for any
| language. Most people are not the HN type that are going to
| live and breath programming.
| inetknght wrote:
| I prefer to be proud that I've never touched Java... for Old
| Reasons. But that said, it's a valuable language.
|
| It's nice to know that other languages have similar problems
| :)
| vips7L wrote:
| I'll probably get down voted, but I honestly really enjoy
| Java. The language, while it has some legacy verbosity, is
| in my opinion the perfect balance of simplicity and
| complexity. It has just enough language features without
| becoming Scala/Rust/C++ levels of complexity, while still
| being competitive on performance.
| WkndTriathlete wrote:
| I can't help but wonder if developers are simply off-put by the
| complexity of the language itself.
|
| Way back in 1989 I was fortunate enough to get Borland's C/C++
| compiler, the K&R C book, and Stroustrup's C++ book - which, at
| the time, was about the same size as the K&R C book. The C++
| language was relatively simple to learn at that time: no STL,
| no odd pointer types, no template metaprogramming, etc.
|
| Fast-forward to 1997 and I'm listening to a talk about C++
| compilers and hear that templates are now a Turing-complete
| language, and how the compiler developers used the template
| language to coerce the compiler into printing out the prime
| numbers.
|
| Fast forward again to 2022 (with trips to Java, Kotlin, Scala,
| and Haskell in between) and I've got a project that requires
| JNI and Python bindings to a core C engine. Great, I'll use
| C++! I proceed to start searching for containers/constructs and
| realize that at least 50% of the C++ language and standard
| library is unreadable to me. I only have a guess as to what a
| `shared_ptr` or `unique_ptr` type is, and I certainly don't
| know when to use them, and concepts/traits outlined in the STL
| documentation seem to be some sort of generalizations that the
| STL might provide default implementations for, but might not?
| What exactly is the syntax and/or type of a lambda function and
| how do they interact with C function pointers? etc., etc.
|
| I get the sense that C++'s evolution has been driven by
| esoteric corner cases that a handful of developers have
| encountered and the language & STL design has been driven by
| those cases. I'm still surprised by how many problems I can
| easily address in something like Scala or Haskell that C++
| simply does not provide the facilities to express easily.
| CoastalCoder wrote:
| > I can't help but wonder if developers are simply off-put by
| the complexity of the language itself.
|
| I certainly fall into this category. At one point I could
| have almost been considered a C++ language lawyer.
|
| But then two things happened:
|
| (1) I got stuck working on codebases that assumed C++11. Even
| now, I'm using Python3 and C++ (mostly 11, with a _little_ 14
| /17 sprinkled in).
|
| (2) The C++ language spec got significantly more complex
| after C++11. Without writing C++14/17 code on a regular
| basis, I just couldn't justify the time spent trying to keep
| up with it.
|
| So for me, the cost/benefit ratio of trying to stay "current"
| with C++ is no longer worth it. I expect to prefer Rust over
| C++ for new projects.
| olvy0 wrote:
| I'm with you mostly, although as the mostly sole maintainer
| of an 22 years old and still evolving C++ codebase (among
| some other responsibilities) I do try to keep up with the
| language. But if I didn't feel this was necessary for my job
| I probably wouldn't do it or at least won't sink too much
| time into it.
|
| I've also programmed in Haskell and I've had the same
| reaction as you, as to the things I can easily express there
| and not in C++. However I think the 2 cultures (Haskell and
| C++) are similar in that they both attract people who like to
| produce clever code which is unreadable to other people, even
| though the base language is not _that_ complicated.
|
| As for your questions:
|
| 1) shared_ptr / unique_ptr: Personally I liked this
| presentation. Watch it on x2 speed until it gets to parts
| that are difficult for you.
|
| https://www.youtube.com/watch?v=xGDLkt-jBJ4
|
| 2) lambdas:
|
| https://www.youtube.com/watch?v=3jCOwajNch0
|
| This is more dense than the previous one. As for your
| question "how do lambdas interact with C function pointers":
| rough explanation is they are not the same, since they can
| possibly allocate memory if they capture. But if they don't
| capture anything they are just like a (static) function, and
| can be converted to a function pointer.
|
| As for concepts / traits, rough answer is that you don't need
| to know about them for everyday work, unless you write a
| library / API for consumption by other C++ developers. In
| that case, they help the compiler provide better/shorter
| error messages in case template functions/classes aren't used
| properly.
| inetknght wrote:
| Excellent videos and thank you for sharing them!
| bodhiandphysics wrote:
| The odd corner case is called data structures... and linear
| algebra, and memory management!
| inetknght wrote:
| > _I only have a guess as to what a `shared_ptr` or
| `unique_ptr` type is, and I certainly don 't know when to use
| them, and concepts/traits outlined in the STL documentation
| seem to be some sort of generalizations that the STL might
| provide default implementations for, but might not? What
| exactly is the syntax and/or type of a lambda function and
| how do they interact with C function pointers? etc., etc._
|
| And that's exactly my point though! `shared_ptr` and
| `unique_ptr` solve (or, at least, simplify) a lot of the
| memory management problems endemic to _all_ C code and old
| C++ code. And they 've been around for over a decade now.
|
| I would absolutely be willing to spend some time with you to
| teach you what new things are, what they do (and what
| problems they _solve_ ), and how to use them without
| introducing new problems. I think several one-on-one teaching
| sessions would help you a lot with that. But one-on-one
| teaches _you_ and not the thousands of other old-experienced
| C++ developers also in your shoes.
|
| > _I get the sense that C++ 's evolution has been driven by
| esoteric corner cases that a handful of developers have
| encountered and the language & STL design has been driven by
| those cases._
|
| While _some_ of the C++ evolution fits that category... I
| would also add that a lot of changes in modern C++17, C++20,
| or C++23 are aimed directly to the masses of C++ developers
| doing "everyday" work. shared_ptr and unique_ptr are
| definitely _not_ esoteric corner cases: they 're driven to
| specifically solve memory management problems that have
| directly contributed to some very significant CVEs in many
| thousands of products.
| gridspy wrote:
| A series of expert-level blog articles guided by your
| experiences teaching a pre-2010 C++ guru would probably be
| well received by other such "ex-gurus." They would need to
| be definitive, detailed, verbose and bring the reader up to
| C++ lawyer in the relevant new feature to be interesting.
|
| A trip through the graphics pipeline has the correct level
| of detail:
|
| https://fgiesen.wordpress.com/2011/07/09/a-trip-through-
| the-...
| sqeaky wrote:
| C++ has fantastic docs, books, videos, so much. You shouldn't
| need to read the std library code, and shouldn't read it to
| know what is safe to do. There are many implementations and
| they differ in details but all have really good standards
| compliance, except where they document deviation (like EASTL
| omits some slow stuff).
|
| If you want to iterate over a container, know promises about
| algorithmic complexity, have strong guarantees about type
| safety, or know what smart pointers promise to do then you
| can get all that without digging into the stdlib's code.
|
| I know this wasn't the main point of your comment but
| shared_ptr can be thought of as a reference counted pointer.
| It cleans up the pointed to object when all the pointers to
| that object go away. It doesn't need to be reference counted,
| there are implementations that do goofy ring lists under the
| hood but all the operations on it are cheap O(1) operations
| and it is only slightly slower than a raw pointer, looking at
| the code might cause someone to miss the promises of
| computation complexity. For object you only want one of there
| is unique_ptr. You give it a pointer or constructor to make
| an object and when that pointer leaves scope it cleans up the
| object. Both are great for managing things like memory,
| connections, file handles, anything you want automatically
| cleaned up when the pointers leave scope.
|
| Not all languages have the robustness that comes with a 40
| year history, so learning last year's hotness and C++ are
| going to be different.
| zabzonk wrote:
| so you have java and python and c, and then you decide to add
| c++ to the mix? not sensible, imho.
|
| and nobody is forcing you to use lambdas - you can do
| everything with other language features
| opportune wrote:
| You can do almost anything in C++ at least three different
| ways. Most places that care about engineering will not have
| you do abusive template metaprogramming or go crazy with
| macros, even though it's possible to do in the language.
|
| The std library is filled with bad implementations that can't
| change because of backwards compatibility. So it's not your
| fault that they look confusing. The pointer types you
| mentioned are actually quite simple, think of them as thin
| wrappers over raw ptrs with constructors/destructors that
| implement counting (for shared ptrs) and whose destructors do
| the delete operation (for unique ptrs, and for shared ptrs
| once they reach 0 copies).
|
| Working with C++ can be easy and fun as long as you aren't in
| a codebase where people went overboard with anti patterns or
| "cleverness".
| thedracle wrote:
| The reality hammer hits quite a bit harder when people are
| playing the "fake it until you make it" game with C++ versus
| other languages as well.
| ryandrake wrote:
| To be fair and assume competence: A lot of C++ programmers have
| been burned by adopting the latest and greatest bling, then
| having to port it to some backwards platform that doesn't have
| a recent compiler. Many of us use the legacy stuff when
| possible, because we know it works, there are already robust
| third party libraries that interoperate with the legacy stuff,
| and it is more likely to be portable than std::omfgbbq.
| sqeaky wrote:
| This is getting better. Businesses that force a specific
| compiler for reasons other than technical merit are being
| punished in the market.
|
| I am currently at a not super advanced C++ shop that has to
| write for several compilers on locked platforms, and even the
| worst/oldest compilers are clang or gcc forks that support
| C++17 and some C++20. We have robust CI and if it passes
| there we can use it (presuming it doesn't violate style
| guide/best practices/code review/etc). It is unlikely we will
| be burned by adopting the latest thing for anytime longer one
| developer is working on it.
|
| I think the companies that are so afraid of upgrading
| software tooling and related processes incurred huge project
| costs because of otherwise needless major rewrites. One I
| worked for a college bookstore management software developer
| that was trying to rewrite their whole point of sale
| software. They were simply crushed by tech debt. Any fix in
| the original software took months and the rewrite wasn't
| finished before the company was bought by a competitor.
| Better unit tests, better practices staying up to date,
| better CI all would have contributed to business success.
| thefourthchime wrote:
| Raises hand. Everyone needs to read "Effective C++", which is
| mostly a book about how not to shoot yourself in the foot
| with C++. The book is old enough now that the way he
| recommends writing C++ wouldn't make it into a PR.
|
| So for that reason, I tended to write C+, which is pretty
| much C+, with some classes.
| paiute wrote:
| after rereading effective c++ with a decade away from c++,
| my main takeaway is that c++ shouldn't ever be used. The
| title should be "55 reasons to not use c++ for your next
| project"
| juancn wrote:
| Also, programming jobs in finance can be really boring.
|
| There are a few neat technical challenges, but usually the
| subject matter is quite dry and fairly annoying (regulatory
| frameworks, etc.). Also there's usually a lot of red tape to get
| anything done.
|
| I don't want to work for a financial company again if I can help
| it.
| psyclobe wrote:
| I'm not dead yet!!
| kibwen wrote:
| _> Hickling pointed to Java, which has long "seemed to be
| replacing C++ itself," but hasn 't._
|
| This is inaccurate. Java completely ate C++'s lunch in the
| enterprise space back around the turn of the millennium. Java
| doesn't need to continue to eat into C++'s marketshare in other
| domains, because it has more than enough mindshare to sustain
| itself (there are more Java programmers than C++ programmers),
| and its very existence keeps C++ from reasserting itself in the
| enterprise space.
| zozbot234 wrote:
| This, pretty much. Long before there was anything like Rust,
| Java was _the_ memory-safe alernative to C++ for larger
| projects. And yes it was slow and clunky, but devs still put up
| with it because the benefits were so compelling.
| YetAnotherNick wrote:
| > Java completely ate C++'s lunch in the enterprise space back
| around the turn of the millennium
|
| When was that C++'s lunch? I might be wrong, but for backend
| dev(majority of enterprise work?) C++ was never a big thing.
| wvenable wrote:
| Before Java, C++ was basically the only game in town for
| frontend and backend. There was always Visual Basic on
| Windows, and C, and a smattering of various pascal flavors.
| anthonybsd wrote:
| Late 90s to early 2000s for sure. Tons and tons of backends
| of various kinds were written in it. If it was Windows it was
| typically running on COM/DCOM, and in UNIX it was usually
| CORBA. Sure, the UI was typically written in something else.
| Dawn of the Web with CGI, and if we are talking desktop
| people would use something like Visual Basic, Power Builder,
| or Delphi. But C++ pretty much dominated that space until
| Java got decent enough and fast enough.
| trashface wrote:
| Late 90s. It was before Java got hotspot. Java prior to that
| was incredibly slow. Microsoft's J++ was a more performant
| runtime than Sun/Oracle java for several years. That
| ultimately became C#/.Net.
|
| C++ had the benefit of running fast but it had all the
| problems you can still run into today. I'll never forget that
| app I worked on where function deep in the stack was
| returning a reference to a local string variable containing
| html...
| 63 wrote:
| Correct me if I'm wrong here, but now that everything is run in
| a docker container anyway, doesn't most of Java's appeal of
| "write once, run anywhere" from the turn of the millennium go
| away? At this point all it has is garbage collection and a
| network effect.
| another_devy wrote:
| Most of enterprise Java jobs in mid/ junior engineering level
| are similar to old times production assembly line, everything
| has a Factory or Impl from dependencies. All you have to do
| is add bunch of methods and connect API's and service bus (of
| course I'm extremely simplifying it, but) it's not hard to
| find people who can do that, also it's not hard to get them
| up to speed for what needs to be done so the churn rate
| doesn't impact a lot to enterprises which is a big win. In my
| personal experience I don't think that's possible with C++ so
| Java may have started with "write once, run anywhere" now its
| more of glue between longer running actors and constantly
| changing workforce
| munificent wrote:
| _> At this point all it has is garbage collection_
|
| You say that like it's a minor thing, but GC is probably the
| largest language-related productivity improvement I've ever
| experienced as a developer, second maybe only to static
| types.
| fsloth wrote:
| Unless you need bare metal speed, or use some specific piece
| of code, never use C++. It is horrible, convoluted mess that
| will consume developer hours into pointless trivia that are
| not issues in anu other languages. So C++ has that as point
| against unless you want to waste developer hours on purpose.
| I'm saying this while writing C++ daily because in our domain
| (cad, geometric computing) for our use case it's the best
| option only because mostly it's the only option.
| twic wrote:
| I don't think WORA was ever a really big deal for server-side
| work. In practice, you know what platform you're developing
| for, and even if you were developing on Windows and deploying
| on Solaris, you would have plenty of opportunities to test on
| Solaris before deploying.
|
| I think the reason that Java beat C++ for boring line of
| business apps is that it was much, much quicker to write code
| which ran fast enough and didn't crash much. Having nice easy
| to use URL/HttpURLConnection classes built in was probably
| also a surprisingly big part of it!
| mk89 wrote:
| Yes and the best part is that companies instead of migrating
| from Java to something lighter are simply trying new things
| like GraalVM which makes native executables.
|
| So your developers can keep on writing crappy and heavy
| spring boot applications (which need 10-15 seconds in best
| case scenarios to to start) and eventually be "graalvm-ed" to
| produce a native executable that starts in < 1 sec.
|
| I mean, that's a brilliant evolution (no jokes). This is how
| you keep in the game without getting devoured by Go and
| similar.
| pessimizer wrote:
| > all it has is garbage collection and a network effect.
|
| It didn't have much of an advantage at the time either. It's
| advantage was that Sun was willing to shower SPARC boxes on
| your university for almost nothing if you were willing to
| move your core curriculum to Java.
| bodhiandphysics wrote:
| Java has a number of other advantages... you can effectively
| develop for Linux on a windows box. The vm architecture makes
| debugging easier. It has a large and useful body of code,
| including lots of libraries and features that ease
| interfacing with legacy systems (like corba and soap)
| thesuperbigfrog wrote:
| The time and effort needed to train Java developers versus
| C++ developers is also huge.
|
| This means more Java developers are available for hire and
| they typically cost less than C++ developers. This reduced
| on-boarding time and reduced cost is extremely attractive
| for enterprises.
| bena wrote:
| I believe it. C/C++ was one of the earlier languages I knew. It
| was my workhorse language.
|
| But now it's been supplanted by C#, Python, and JavaScript. And
| even with JavaScript, I'm constantly finding out stuff that was
| new a few years ago that makes the language better and easier to
| use.
|
| I've taken a look at C++ recently and there's so much new stuff,
| it would almost be like learning it all over again. Hell, even C#
| would be like that if I were to compare it from when I first
| learned it to what it looks like now.
| BrS96bVxXBLzf5B wrote:
| I could have been a talented C++ developer. Hell, I _am_ a good
| C++ developer. I should be, I've been doing it for a decade.
| Across a range of projects, from hardware to web backends to
| games and art.
|
| But aside from a brief 3 years as a C developer (embedded
| hardware product) I've never been close to being one. Because
| when I was coming out of university seven years ago with a good
| CV and projects I could competently talk about, and I _could_ do
| the whiteboard segments, somehow I ... couldn't do them the way
| they wanted? And they, the very sparsely spread places with
| listings at the time, were offering no money for a new grad to
| somehow make their way across the country to interview, only to
| be offered a low salary (the C job I got was at the risk of a
| PS180 train ticket three weeks before I would have had nowhere to
| live).
|
| Now? I maintain a fleet of Wordpress sites for a digital agency
| for a modest PS40k a year as the company's sole "someone who
| knows anything about Linux" person. Because my coworkers are
| lovely, my boss doesn't stress about anything and lets us flex
| our time and the clients are nice. Money is tight and definitely
| less than my skillset but going through the hoops of the "clever"
| side of the industry to be well paid and well stressed sounds
| daunting. There was no nurture for anyone not conforming to a
| very specific template which shows its face on the ranty side of
| Twitter.
| oxff wrote:
| Most of C++ programming is tied in legacy code and tech debt,
| that is why it has that image. Only so few modern green field C++
| projects with latest standard out there.
| lubesGordi wrote:
| That's true, but if you can find a place that isn't just new
| features all the time and you can refactor, it's so satisfying
| cleaning up some shit ancient c++ with clean modern c++.
| fouronnes3 wrote:
| It's getting harder and harder to justify using even the most
| bleeding edge C++ for a new project.
| cjensen wrote:
| For anyone looking for a junior who knows C++ in Canada, we've
| had good luck with Sheridan College in Oakville ON.
| wheelinsupial wrote:
| Is this for graduates coming directly from high school or are
| you seeing success with people that already hold degrees and
| are going for retraining or up-skilling?
| cjensen wrote:
| New college grads who went to college right after high
| school. They have a strong intern program, so the students
| usually have some real-world experience using C++.
| a-dub wrote:
| i don't think the use cases for c and c++ have changed all that
| much in the last decade.
|
| the sheer quantity of application stuff that has been written in
| very high level languages has.
| rpep wrote:
| I worked in C++ in the UK for a number of years and interviewed
| for a couple of positions like these. The main reason I didn't
| want to work for a financial company is that they insist on high
| number of working hours and being located in-person in London.
|
| When I studied Physics, I did 2 years (4 semesters) of C++.
| Nowadays, nobody would do that, you'd learn Python by default.
| [deleted]
| ninefathom wrote:
| To quote Yogi Berra, "it's deja vu all over again."
|
| Those of us of a certain vintage remember this precise issue with
| Fortran a couple decades ago, and those out there of a certain
| further vintage probably remember it with COBOL. So on and so
| forth back through PL/I, Algol, and so on to the dawn of time.
|
| While there have certainly been consequences of the dearth of
| COBOL and Fortran devs, ultimately the world has thus far
| survived. We'll survive the obsolescence of C++ (if indeed that's
| what this is).
| shmerl wrote:
| I think the general idea of Rust seen as more interesting to
| invest efforts in is on point.
| Brystephor wrote:
| Why doesn't c++ offer a language version that's trimmed down to
| "modern" rules? Meaning all things that were deprecated, or not
| recommended, are cut out of the language. What I find difficult
| is that there's several ways to do the same thing but each option
| has some nuance or gotcha with it. This is said as a beginner who
| did half of learncpp
| thesuperbigfrog wrote:
| >> Why doesn't c++ offer a language version that's trimmed down
| to "modern" rules?
|
| What part could be removed without breaking backward
| compatibility?
|
| Depending on what is removed and how, it creates a subset that
| is not fully C++.
| Brystephor wrote:
| It'd be a different version that's not intended for backward
| compatibility. This would be beneficial for any new projects
| or new learners who don't need to sift through decades of
| changes.
|
| There can still be the standard updates every 3 years for
| backwards compatibility, but Id assume version upgrades don't
| happen very frequently. Meaning, if a project is started on
| c++11 then it's probably going to stay on c++11 indefinitely,
| never making it to c++17 or some other later version.
|
| If that's true then that would imply in general the projects
| using c++17 or later are created from scratch using that
| standard and therefore wouldn't suffer from backwards
| compatibility.
|
| This is all said as someone who works with Java where I don't
| see folks migrating from Java 8 -> 11 or later.
| gridspy wrote:
| In Rust this is done using Cargo (the build system) and
| each crate (library / binary) can choose a compiler edition
| that gates certain features which are not backward
| compatible.
|
| You can use (depend on) a crate from your code that uses an
| old edition.
|
| In C++, your idea would require enforcement at the compiler
| level but the linker should still link both "old" and "new"
| C/C++ together. Then the switch is done on a .cpp file
| (translation unit) level.
|
| However the culture around C / C++ compiler development
| with standards and multiple compilers would require huge
| committees to decide what is "modern C++." There might be a
| lot of debate.
|
| Much of the innovation in Python, C# and Rust is in how the
| process of language and standard library development is
| managed in the community. I wonder if C++ could do that?
| rufius wrote:
| This seems like a good thing frankly. C++ sucks to work in (I
| have 10 years exp with it professionally). I'd never start a new
| project in C++. Maybe C for an exotic arch, but not C++.
|
| Good riddance.
| nradov wrote:
| Talent is a myth.
|
| https://www.inc.com/graham-winfrey/malcolm-gladwell-on-hirin...
|
| Any developer can learn C++ (or at least the subset used in most
| real-world code). It's not like theoretical quantum physics or
| something. Hire people and then send them to training.
|
| Can't afford to train your employees? Then you don't have a
| viable business in the first place. Might as well liquidate and
| return the capital to investors instead of wasting time on a slow
| death spiral.
| JonChesterfield wrote:
| Trading is struggling to find great C++ devs because they're all
| obsessed with working from London.
| dsign wrote:
| The last time I searched for jobs, there were two competing
| automotive makers among the prospective employers. The one that
| offered the C++ position for programming Lidar systems offered a
| lower salary than the one that just wanted a generalist to
| wrangle scripts and systems. Beats me.
| hpcjoe wrote:
| Auto companies notoriously pay their people poorly. They are
| losing many talented engineers as a result. I know quite a few
| in the industry here in Michigan. The engineers who remain at
| the autos, are blown away by the salaries their former
| colleagues are getting from SV companies.
|
| I was mentoring a EE who wanted to up his game. He wanted to
| get into programming, and I pointed out that Python, C++, etc.
| are in demand at many companies right now. I asked him for his
| salary range, and for a 50+ year old engineer with 20 years of
| experience, it was pretty awful. Though, completely normal for
| the autos and their suppliers.
| bluedino wrote:
| I found it equally hilarious that (at the last place I was) the
| Python devops jobs paid 50% more than the core developers of
| the company's core product.
| ch4s3 wrote:
| I wonder if this partially explains some of the issues car
| manufacturers are having with LIDAR systems, other than the
| inherent difficulty of course.
| yewenjie wrote:
| How hard is it to learn only the modern part of C++ coming from a
| high-level language world?
| markus_zhang wrote:
| Well, hire me and train me. I'm a mediocre Python data engineer
| but self taught myself a bit of C and C++ plus I don't ask for
| high salary. Something like 90K CAD is good for me.
| stefanos82 wrote:
| I came here to say more or less the same.
|
| I have been playing with C++ since 2003 (university years) and
| still haven't had any opportunity to get hired due to my lack
| of previous professional experience.
|
| For some reason, my web development experience does not matter
| for them, nor they care that I do my best to learn from C++
| experts we all know.
|
| If they are so scared they cannot find talented C++ developers,
| it's about time to start training people and let them gain some
| experience.
|
| Do they actually hire inexperienced people and train them or
| are they just complaining for years now (?); because quite
| frankly, I have been reading this since the release of C++11
| and still haven't they found their "talented C++ developers"!
|
| I'm here people! Hire me, train me, and prove me wrong with
| what I have said!
| markus_zhang wrote:
| Totally agreed!
| 22SAS wrote:
| Most places need people who have production C++ experience. If
| someone is self-taught and hasn't done production-level C++,
| then some places are willing to train but don't expect to be
| hired in anything above a junior-level role.
| bsenftner wrote:
| I'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.
| Quarrelsome wrote:
| I wouldn't take that personally. In my experience most
| recruiters are complete idiots. The vast majority of
| recruitment agencies in my geography (UK) just employ children
| for recruitment roles and as such all their understanding of
| tech is almost entirely cargo cult and buzzword driven. This is
| why every tech CV that goes to a recruiter should have a
| "buzzword page" so they can play pairs, feel like they're
| adding value and get out of your way.
|
| When a recruiter is like that then their function is simply to
| forward your CV and arrange an interview. They are not
| qualified to actually vet your ability in any way.
| FpUser wrote:
| That is why I think it is never good idea to talk to
| recruiters. Most of them would not spot a difference between
| golden laying goose and some mediocre person. There are enough
| companies out there where one can come and apply without going
| through a recruiter.
| jbluepolarbear wrote:
| 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.
| eredengrin wrote:
| > One time they were reaching out to me about a design engine
| I wrote and didn't even realize.
|
| Reminds me of this story
| https://brendangregg.com/blog/2021-06-04/an-unbelievable-
| dem...
| lordnacho wrote:
| 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.
| Decabytes wrote:
| I'd love to learn C++ and jump ship from the Data Science job I
| work, but I'm not even sure where I would start. Sure there are
| lots of videos about programming in Modern C++ but the reality is
| none of the codebases you work on will probably use. And a lot of
| places just use a subset of C++ or just C with classes, so then
| how much of C++ do I actually need to know? That coupled with the
| fact that they are paid less, makes me think I should just learn
| a python web framework since I already know python, and some Html
| and CSS and just apply to a python job
| arunmu wrote:
| I have been a big fan of C++ and have had used it for about 8-9
| years professionally as well as for side projects. The baggage
| that comes with it is just not worth it. My recommendation for
| any new project is to go either with Go or Rust as a C++
| replacement unless the environment or hardware or resource
| constraints does not allow you otherwise.
|
| As an individual developer, learning and being an expert in C++
| intricacies is not worth the time and effort. Instead learn more
| about data layout in memory, hardware, language tooling etc and
| write code accordingly in a much better language as per the
| _need_ and C++ would really only qualify for very niche
| requirements.
| gavinray wrote:
| 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 inheritance, again
| difficult to find examples of
|
| - C++'s way of "implementing" interfaces (IE iterator<T>) by
| having a magic defined set of type aliases and methods is not
| intuitive for me
|
| - Writing code to control things like parallelization and thread
| scheduling that's portable across libraries is difficult. I think
| std:: executor is supposed to fix this but if I'm manually
| scheduling threads and I want to use IE oneTBB it's not obvious
| how to do this.
|
| - Dependency and package management is a nightmare. Need to
| condense CMake + vcpkg into a Cargo like tool and make it a
| standard
|
| - error messages are indecipherable. GCC 13-dev colors make this
| a bit better but human-written "ELI-5" errors succinctly
| explaining the problem and suggesting a solution (like Rust)
|
| - flags like "-fsanitize=address,leak,undefined -fanalyzer
| -Wthread-safety -D_FORTIFY_SOURCE=" should be baked in to a
| default "dev"/"debug" mode newbies shouldn't need to know/think
| about
|
| - Profiling and instrumenting/monitoring should be a few CLI
| flags with nice UI visualizers (IE LLVM X-ray)
|
| - I have to Google what headers cstd/std stuff comes from half
| the time
| mk89 wrote:
| 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 make C++ decent are often found in C++
| 20/23, for which there are woefully few resources
|
| Somehow yes, but I think lots of cool things happened in 11 and
| 17. At least when I read the docs, it seems so. C++20 seems to
| have simplified and ported a lot of more modern features to the
| language, though. But 11 was a game changer from my
| understanding.
|
| > - Dependency and package management is a nightmare. Need to
| condense CMake + vcpkg into a Cargo like tool and make it a
| standard
|
| Tooling is indeed something that requires a sort of unofficial
| community decision to say "just start with this and this".
| That's so true! But that also goes against the main philosophy
| of C++ which makes it so super cool!
|
| > - flags like "-fsanitize=address,leak,undefined -fanalyzer
| -Wthread-safety -D_FORTIFY_SOURCE=" should be baked in to a
| default "dev"/"debug" mode newbies shouldn't need to know/think
| about
|
| Did you try project_options[0]? I recommend it to all newbies
| like me. Just set the "enable_developer_mode=true" and you get
| all that stuff for free.
|
| > - I have to Google what headers cstd/std stuff comes from
| half the time
|
| In Clion you can cmd+click on the symbol and it leads to the
| header.
|
| As a final note, another recommended resource is
| https://github.com/cpp-best-practices/
|
| [0]: https://github.com/aminya/project_options
| ackfoobar wrote:
| > 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.
| gridspy wrote:
| Rust's dynamic traits are like Java or C# Interfaces.
|
| Rust's Static traits are used like C++ templates but with
| more compiler checks and guidance.
|
| In both cases, you can separate the code that implements
| the trait from the class itself (like a partial class). In
| Rust you can also retroactively declare a trait and then
| implement that trait for a class you like (even someone
| else's class, or a standard class).
| mk89 wrote:
| you're right, Scala has also type classes, though.
| Generics, traits, variance, etc., are all quite
| sophisticated in Scala. I wouldn't say it's taken from
| Rust. The idea had been there for a while.
| gavinray wrote:
| That project options tool is pretty neat, thanks for sharing!
| badpun wrote:
| Let's add the fact that no IDE right now fully supports C++ 20.
| Visual Studio comes closest, but for example modules still
| don't really work well.
| bogomipz wrote:
| I would be interested in hearing what modern resources you have
| been using that have been helpful and which ones you would
| recommend.
| gpderetta wrote:
| FWIW the concept feature of c++20 has very little in common
| with rust traits. C++ concepts are closer to type assertions
| and aren't really a type system for templates.
|
| The old c++0x concepts proposal was much closer (and of course
| precedes them), bit turned out it was harder to make it work.
| jjtheblunt wrote:
| "IE" ?
| gavinray wrote:
| Yeah -- I thought it meant something along the lines of "for
| example" or "one instance being"?
| mrfox321 wrote:
| e.g. -> example
|
| i.e. -> in other words
| pessimizer wrote:
| e.g. -> Egg-zample
|
| i.e. -> the other one
| mkl wrote:
| i.e. -> In other wErds
| Zolomon wrote:
| id est (i.e.) = that is (literally "it is")
|
| exempli gratia (e.g.) = for the sake of example, for
| example
|
| See: https://en.m.wikipedia.org/wiki/List_of_Latin_phrases
| renewiltord wrote:
| Usually people use the lower case with dots, i.e. `i.e.`.
| Also one usually uses `e.g.` in those situations with `i.e`
| reserved for "that is". To illustrate:
|
| "We had to come up with some way to cut our burn rate, e.g.
| lay off (i.e. fire) some of our workforce; cut facilities
| (i.e. get out of our leases),..."
|
| As an aside, I wish there were "minor aside" conversations
| that wouldn't pollute the main thread so I could respond
| without occupying massive comment-space.
| jjgreen wrote:
| In AE it's also usual to have a comma following them, so
|
| "We had to come up with some way to cut our burn rate,
| e.g., lay off (i.e., fire) some of our workforce; cut
| facilities (i.e., get out of our leases),..."
|
| The reasoning being that these expressions are
| "parenthetic and should be punctuated accordingly" _The
| Elements of Style_
| larsrc wrote:
| Surely not Internet Exploder?
| fsloth wrote:
| C11 resources are just fine to start with. That will bring you
| to "modern C++".
|
| C++ is not about bleeding edge. Nor is it about being a good,
| modern language.
|
| It's key feature is to be able to tweak performance based on
| profiler data.
|
| So, you want to write code you understand well enough, so you
| can adapt it based on the feedback profiler gives you.
|
| If you don't need to write code that needs to get every last
| bit of performance, or you don't have to use some specific
| libraries, or maintain some legacy code, there is no reason to
| use C++.
|
| Also, a humorous rant:
|
| 1.5 years? I've been programming C++ professionally for 15
| years and it's still a daily struggle. It's a minefield of
| footguns, within which are buried unexploded munitions from
| previous generations, all administered by a posse of savants
| gleefully adding more and more convolutions to the language to
| "modernize" it.
|
| I have to also Google what headers cstd/std stuff comes from
| all the time
| rjzzleep wrote:
| I actually just tried to play around with what seems to be a
| "modern c++" boilerplate project.
|
| It uses CMake, conan for packaging, clang-tidy and cpp-check, and
| has templates for fuzz and unit testing[1].
|
| I found it because qtcreator and kdevelop were weirdly clunky and
| created partly broken qt projects and I figured I wanted to add a
| package manager and qt to the mix.
|
| The template looks really fancy, but it's so incredibly slow, to
| the point of being unusable.
|
| It's a ramble yes. But the point is modern C++ tools seem to have
| added some niceties to the language, but they also brought more
| of the main C++ issues, i.e. slow compile times and nasty
| boilerplate in the build process. Yes, I realize CMake isn't
| modern and there are a bunch of new build tools.
|
| [1] https://github.com/cpp-best-practices/gui_starter_template
| bogwog wrote:
| That is the most bloated boilerplate project I've ever seen.
| Does anyone actually use this for their projects? I would hope
| not. I know Javascript people are used to starting a project
| with a template/boilerplate, but that's not a good idea in C++
| land. You actually need to understand the stack you're using,
| and all of the tools (unless you're working on a team, in which
| case that could be someone else's responsibility)
|
| Also, QT projects aren't real C++ since they require an
| additional preprocessor to compile custom syntax additions for
| "signals" and "slots". As a consequence, tooling for those
| projects tend to be more complicated and clunky.
|
| This linked project seems to be trying to stuff as many things
| as they possibly can into a hello world project. With Conan +
| CMake you only need like 3 files total in your entire project
| for something like this: * conanfile.txt: for
| declaring requirements/dependencies * CMakeLists.txt:
| describe how to compile your project * main.cpp: source
| code for the hello world app
|
| Also,
|
| > Yes, I realize CMake isn't modern and there are a bunch of
| new build tools.
|
| No!! That thinking is a trap. CMake _is_ modern, and using
| something else is more likely to cause problems for you and
| anyone who might want to use your project. That boilerplate 's
| is a bad example. A fully functional SDL2 hello world with
| Conan can be done with a ~4 LoC CMakeLists.txt.
|
| Unless you have a very good reason (there _are_ good reasons,
| but they 're the exception rather than the rule), don't build
| your C++ project with anything other than CMake.
| P5fRxh5kUvp2th wrote:
| I wouldn't put much stock into such starter templates, the
| developer who put them together has a goal and priorities that
| are not yours.
|
| QT tends to be particularly painful outside of QTCreator so I
| also wouldn't use that as a general knock against C++.
|
| having said that, C++ build times are slow due to both the
| #include mechanism and templates. The C++ modules coming will
| help deal with the #include mechanism and templates can be
| instantiated to assist the compiler.
|
| None of it is amazing, but the compile times are better than
| rust imo.
| Night_Thastus wrote:
| C++ modules has been promised for a long time, I wouldn't
| hold my breath on it coming anytime soon.
|
| As for build times, it is sadly very easy in C++ to have long
| build times. Avoiding it takes careful work, knowing when and
| what to include, when to forward-declare instead, and always
| maintaining includes as requirements change, etc.
|
| There's nothing to make that process any easier or automatic,
| which is very frustrating. There's the include-what-you-use
| project, but I could never get it to work.
| P5fRxh5kUvp2th wrote:
| I was under the impression C++ Modules were accepted in
| C++20, although I'm not sure how complete the
| implementations are.
|
| But yes, C++ build times are why I'm not a fan of header-
| only libraries, especially ones that have templating in
| them.
| codalan wrote:
| The pool of C++ devs hasn't dried up.
|
| They're just working on other things in other languages.
|
| If there was strong demand for embedded C/C++ devs that paid
| well, I wouldn't be doing C# REST APIs on Azure. Not that I don't
| enjoy working on APIs, but I do like working with bare metal
| more.
| writeslowly wrote:
| When I graduated from school in 2010, my primary experience from
| a previous internship was working in an outdated style of C++.
| Interviewing for C++ positions was so intimidating that I ended
| up removing all references to it from my resume, essentially
| disavowing that I had any knowledge of the language, and applying
| for Java and Python jobs instead.
| Ragnarork wrote:
| I find it funny that the headline states it as a general trend
| while it's looking at it only through the prism of "the
| finance/crypto industry struggles to find C++ developers".
|
| Maybe part of the problem is that people don't want to work on
| your bullshit crypto products, or just on HFT.
| joezydeco wrote:
| Bingo. I've been approached continuously by recruiters looking
| for finance and/or crypto firms and I won't go anywhere near
| it.
|
| 2x the salary but 10x the stress with type A finance bros
| yelling at you constantly? Fuck that.
|
| Full disclosure: I'm a sucky C++ programmer. If if they're
| approaching _me_ that means they 've chewed up everyone else
| they can find. So, another red flag.
| [deleted]
| 22SAS wrote:
| >2x the salary but 10x the stress with type A finance bros
| yelling at you constantly? Fuck that.
|
| I am in that industry and this hardly happens. Probably at
| places like Citadel, not otherwise. In HFT's, traders are
| basically quantitative traders now. They do both strategy
| development and trading i.e they have a strong STEM
| background and are much different than finance bros at most
| traditional hedge funds.
| badpun wrote:
| > If if they're approaching me that means they've chewed up
| everyone else they can find. So, another red flag.
|
| This reminds me of an old Woody Allen joke: I wouldn't want
| to join the club that would have standards low enough to
| accept me as a member.
| daveslash wrote:
| Yep - you're right. This is a red flag I learned to recognize
| when I was young. When I turned 16 and could legally apply to
| jobs, I walked into a local restaurant and asked about a
| dishwashing position. I filled out the application right in
| front of the hostess, handed it to her, and without her even
| looking at the name she asked _" Can you start today?"_. I
| took the job. I know better... _now_....
| gigel82 wrote:
| The comments here worry me. I've been programming C++
| professionally for 15+ years and I think my comp is pretty good.
| I didn't shop around though (maybe I should just to see what the
| market is like, but I hate LeetCode or whatever it is kids do
| nowadays :) ).
|
| We've noticed the C++ pool getting dry when hiring though;
| nowadays everyone that comes to interview uses Python and
| JavaScript. We're switching part of our stack to TypeScript
| because we simply can't find qualified C++ developers (or folks
| in general willing / able to learn C++).
| bogwog wrote:
| What industry are you in? From the comments, what I've gathered
| is that anything in the embedded space is awfully underpaid
| unless you work for Google/Apple/Microsoft/etc.
|
| And finance can pay well, but web development pays better.
| gigel82 wrote:
| We're doing cross-platform client applications (primarily
| Windows desktop apps with some macOS and a bit of
| iOS/Android).
| ezoe wrote:
| I have no interest on HFT or crypto currency the article says
| lacking C++ programmers. I consider them ponzi scheme. It doesn't
| create any value to the society to me.
| varelse wrote:
| strangattractor wrote:
| Sort of like complaining the talented Cobol and Fortran
| developers are running sry.
| ho_schi wrote:
| Actually I've learned C++ in the past years and want to look into
| a working in embedded development. Now I'm reading that the
| industry is in need for C++ developers but paying bad at the same
| time? I'm confused.
| smolder wrote:
| So are the ones hiring, apparently.
| ironmagma wrote:
| Employers might have to... gasp... train their employees.
| justinlloyd wrote:
| I can code in C++, have been coding in C++ since it was first
| released, and C before that, on almost ever conceivable platform
| and processor. I've done some seriously hard-core systems
| programming, hard real-time work, deep embedded kernel level
| projects, and stupendously fast algorithms. But the thing is, I
| can get paid 2x to 3x as much to write Python or Typescript, and
| I'm not in some toxic fintech/cryptobro environment. Every
| employer that has hired me for my C++ has been "not chill" and
| just outright toxic at times, and the pay is crap. Why put myself
| through that?
|
| Footnote: I've heard the same nonsense about not enough COBOL
| programmers (I've reluctantly done quite a bit of COBOL over the
| years) with companies desperate to hire and will pay $$$ for the
| privilege of retaining them, but when I talk to these desperate
| companies willing to pay top rates for a decent COBOL developer,
| I find out they are offering less than I was making 20 years ago
| and choke when I say "to get me to move, you'd need to pay at
| least 10% more than what I currently make."
| jll29 wrote:
| Dear finance folks: Please do write your trading systems in Rust;
| then at least the poor beeper-wearing support folks maintaining
| the code doesn't have to come in on the weekend as often to debug
| those unnecessary null pointer & dangling reference errors
| causing crashes.
| Rochus wrote:
| Rather stop doing HFT.
| FpUser wrote:
| Dear language righteous. I am one of those "poor souls" who
| writes web and other enterprise backends in C++. I can assure
| you that I do not come on weekends / woken up at night to fix
| "null pointer & dangling reference errors causing crashes" or
| memory leaks. Modern C++ along with libs and tooling provides
| more than enough features to be done away with those on backend
| style development. I just simply do not remember the last time
| I had this kind of problems.
|
| Firmware is a bit different but frankly all of the gadgets I
| own work just fine ;)
|
| Edit. I am not a C++ zealot. Have used and using many
| languages.
| mempko wrote:
| Rust is solving for the wrong problem. Null and dangling
| pointers aren't the main problem in building financial trading
| systems (I built a financial trading system).
| sedeki wrote:
| What do these presumably highly-paid C++ developers work with
| exactly? And what is their background? How much do they make in
| London?
|
| I have a degree in mathematics, am ~36 years old, but only worked
| as a web dev.
|
| I'm thinking about taking courses in mathematical statistics or
| physics. I want to "get out" of web dev. This type of job would
| be a huge step up for me. Just unsure how to begin a career
| change...
| United857 wrote:
| C++ is still dominant in the AAA games world, and there's no
| signs of it ending its reigns at least at the engine level.
|
| IMO it's not so much that there aren't talented C++ developers or
| "Rust is the new hotness", it's the long standing WLB/culture
| issues of the games or the finance industry that's causing many
| of them to burn out and move to FAANG/Microsoft/etc. (I'm one of
| them)
| [deleted]
| speeder wrote:
| I am one of the few stubborn people I guess, that insists in
| wanting to work with C++, C, Lua...
|
| All I see is Python, Ruby, JS, Java, etc... jobs. So why bother
| learning a language that has no jobs for it? No wonder the amount
| of developers are decreasing. It is just offer meeting the
| demand.
| eBombzor wrote:
| Talented as in knowing how to use C++ footguns or talaented as in
| understanding most C++ features but having the wisdom to avoid
| 90% of them?
| nnoitra wrote:
| joker99 wrote:
| It gets worse: try finding a _Windows_ C++ developer with kernel
| experience. They seem to be a rare breed... And finding one who
| has even a bit of security experience and a defensive coding
| style is even harder
| VintageThinkpad wrote:
| RadixDLT wrote:
| c++ will be replaced by Carbon or D and rust and others
| DeathArrow wrote:
| >Where are all the C++ programmers?
|
| I'm still here, but I switched from C and C++ to C# and .NET and
| from desktop and games and mobile apps to backend.
|
| I feel more productive, the wage is better and there are more
| jobs.
| stormbrew wrote:
| Once upon a time I knew the c++ standard like the back of my
| hand. I was excited about the first few standard revisions, and
| read proposals as they came out.
|
| Now I think it's a dead end and would sooner start a new project
| in C than C++ (but would prefer neither). The language that
| exists now is spending all its efforts fighting yesterday's
| battles, and it's rapidly losing relevance.
|
| It used to be my bread and butter, but the only way I'd take a
| job that was for c++ programmers now is if it was to help migrate
| it to a language that lives in 2022 instead of endlessly
| relitigating the PL battles of 2008.
| n4jm4 wrote:
| So hire Rust and FPGA devs.
| zabzonk wrote:
| there is a limited pool of talented programmers in ANY languge.
| nradov wrote:
| Talent is a myth. The pool is only limited at a particular
| point in time. Employers who require skills in a particular
| language can just provide training.
| FpUser wrote:
| I am not sure what do they mean under "talented C++ developers".
| If this is a person who knows all of C++ and constantly uses all
| the features then sure, you will not find too many people with
| this kind of experience.
|
| Reason being I think is that they're not really needed in almost
| all cases. Most people will do just fine using specific subset
| that is adequate for a given project.
|
| What is really needed are people who can think and "properly"
| architect and implement the system. They're way more valuable and
| will do just fine in most of the languages.
| Kelteseth wrote:
| > People are seemingly scared away from the language by a
| terrible stigma: the notion that it is a legacy program.
|
| My personal experience: Universities (in Germany) simply stopped
| teaching C++. Most of it is now Python or C#.
| stingraycharles wrote:
| Did they?
|
| I know that when I did my CS in early 2000s, they didn't even
| teach a specific language -- you were expected to pick one up
| yourself in your own time.
|
| Perhaps it's just part of a bigger zeitgeist that people just
| care less about C++ than they did before, faster than the
| actual job pool is decreasing?
| LeanderK wrote:
| That hasn't changed, you are still expected to pick one up
| yourself except (for me) Java, the first and only language
| that really got "taught". Maybe that was C++ a few decades
| ago or something. We had to do a little bit of C for some
| system programming lecture.
| tannhaeuser wrote:
| A recent curriculum of languages taught at a German TU I
| skimmed over includes C, C++, and Haskell. Can't help but agree
| with that choice: C gives you understanding of low level
| operations and appreciation of higher level concepts such as GC
| and/or verification etc. while Haskell lets you experiment with
| functional and logic idioms, type theory, DSLs, etc. Starting
| with Java or C# might be ok for training and getting a job, but
| would be unsuitable for foundational education IMO.
| zaphar wrote:
| I mean, I don't think it's a legacy language at all. But I do
| think it's a minefield of annoying problems with no two
| codebases speaking the same subeset of C++ evolved to work
| around those annoying problems.
|
| All told I would fine it more frustrating to work in C++ than
| enjoyable.
| soinus wrote:
| Would not say it's true at least for robotics related fields. I
| personally taught C++ some years ago and the new guys have
| taken over since, adopting and improving on my course. There
| are many specializations where C++ is still a must.
| bodhiandphysics wrote:
| Yes... it's the lingua franca of graphics and scientific
| computation (including low level ML)
| hardware2win wrote:
| And thats right choice
|
| Why students should waste their sacre time on mess of c or cpp
| world where even basic things may be crazy like strings
|
| Stop wasting peoples time on subpar technology and let them
| learn algorithms, ds and foundational knowledge instead of
| quirks and pain
|
| Go, python, c#, etc. are way better for students
|
| Later teach them Rust
| Barrin92 wrote:
| Not surprised to see Python but when I went to uni in Germany
| 10 years ago Java absolutely seemed to dominate as a teaching
| language (and on the job market). Has C# gained ground?
| Kelteseth wrote:
| Yes, Java is still big. Python is popular because it is a
| synonym for machine learning at this point. C# mostly because
| of Unity3d is the preferred game engine.
| lumost wrote:
| 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?
| UltraViolence wrote:
| new / delete?
| bodhiandphysics wrote:
| I use malloc more often than I use new and delete!!!
| insanitybit wrote:
| Having learned C/C++ as my first languages I can say I'm
| quite glad for it. I was able to learn so fucking much.
|
| 1. Object oriented programming, complete with inheritance and
| virtual dispatch
|
| 2. Pure Functional Programming, lambdas, const correctness,
| template metaprogramming
|
| 3. Type system fuckery - the things you can do in C++'s TMP
| is insane. Both nominal and duck typing in the language.
|
| 4. Hardware - I watched so many talks on how CPUs work that
| explained things via C/C++. I learned about tools like
| valgrind and cachegrind, how to profile code, etc.
|
| 5. Security - The original reason I wanted to learn them, to
| understand how to exploit C and C++ programs and their common
| vulnerabilities
|
| 6. Data structures - C++ is awesome for building data
| structures from scratch and understanding their low level
| semantics
|
| I don't want to write them professionally, but learning them
| was massively helpful, with skills propagating through every
| other language I've used.
| gridspy wrote:
| 7. Fundimental underpinnings - Every other language is
| written essentially in C - you can often understand how
| their features WORK if you know C extremely well.
|
| ... I'd argue that 1,2 are covered by rust. 3 and 6 by
| unsafe rust.
|
| Once you have that, a transition to pure C for the full 7
| makes sense, and would be trivial for a rust dev.
| insanitybit wrote:
| I'm fairly proficient in Rust and I think it has its own
| strengths for learning, but its own downsides too.
|
| Pros:
|
| 1. Way easier to get "live" help, I've found the barrier
| to ask for Rust help is lower than any other language
| I've ever used (and I've used a lot)
|
| 2. Way easier tooling like cargo, error messages are far
| better, especially with regards to generics vs templates
|
| 3. Some things are more explicit in Rust. Like `Box<dyn
| Trait>` is very explicit about dynamic dispatch, I don't
| recall that being the case in C++.
|
| Cons:
|
| 1. Rust's "codex" of knowledge is nowhere near C++. There
| are tons of conference talks, books, blog posts, etc on
| C++. Not just on C++ but also on hardware as seen through
| C++, security, etc.
|
| 2. Implementing low level data structures in Rust is an
| advanced practice. Implementing them in C++ is trivial. I
| get that it's trivial because C++ doesn't give a fuck
| about your pointers, but if you're just trying to learn
| data structures you really just need to be focusing on
| happy paths and whatnot (as a student).
|
| So idk, at this point I tend to recommend Rust, but I
| also end up having to link people to talks on C++
| sometimes! Herb Sutter and Scott Meyer are amazing
| speakers and writers and that's a very hard thing to
| replace.
| magicloop wrote:
| I'm glad someone pointed out these things, as I concur. I
| learnt C++ via the C++ programming language book, and it
| gave me many of the above benefits/insights. (The book has
| its faults though). It is akin to trawling through the CLRS
| book. It does make you a better programmer but no-one knows
| why. (An attempt at sarcasm - I know most of us never need
| to do advanced data structures/algorithms but it helps
| refine the mind for programming challenges).
| __turbobrew__ wrote:
| I definitely would not advocate teaching students C++.
|
| C on the other hand is a relatively compact language and is
| the lingua franca of operating systems and shared libraries.
| ngngngng wrote:
| My recent hot take is that students should never learn on a
| language older than they are. There are so many options,
| why did I have to battle linker errors in my intro to CS
| class with C++? Nothing we were doing required C++.
| P5fRxh5kUvp2th wrote:
| I learned programming in the 90's using C++.
|
| When someone expresses this intent I always ask the same
| question. Am I a supergenius or are you mistaken?
| cesarb wrote:
| The C++ of the 90s was a much simpler language, closer to
| "C with classes" (and often used as such) than modern C++.
| It was much easier to learn everything about C++ back then.
| hardware2win wrote:
| How is this relevant?
| P5fRxh5kUvp2th wrote:
| boomer sooner
| hardware2win wrote:
| The point is
|
| Just because we can teach programming with cpp, does it
| mean that we should?
|
| Seems like no.
|
| There are better designed langs and ecosystems that allow
| students to move faster.
|
| Go python c#
| lumost wrote:
| One could learn in C++ using a variety of methods...
| including the ignore memory management variety.
|
| The question is why? For a student learning dfs for the
| first time or hash tables/queues etc. python will be much
| easier to learn. Java/rust/go will likewise be easier if
| you want to talk about types.
| hedora wrote:
| 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.
| P5fRxh5kUvp2th wrote:
| 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.
| gridspy wrote:
| 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?
| soinus wrote:
| 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.
| gridspy wrote:
| 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.
| WhiteDawn wrote:
| 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 schools need to teach employable C/C++ skills,
| but C/C++ is a great language to play with and experience
| these core concepts.
|
| However I'm not sure if the value in learning these concepts
| are real, or it's just my own interests/nostalgia. You can
| have a successful career in this industry without having to
| manage a single byte of memory, and it arguably makes sense
| to accept abstractions at their face value so you can focus
| on what builds your skills/product.
| sqeaky wrote:
| 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 how I should put those two
| things together is not something that can easily be
| googled.
|
| I agree it doesn't need to be a first year thing, but it
| does need to be part of a robust computer science
| education.
| gridspy wrote:
| 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.
| mywittyname wrote:
| > pointers, structs, memory layout, endianess, pass by
| reference, compilers etc.
|
| C++ is a bad language to teach any of these concepts. Sure,
| people will be exposed to the concepts, but they are
| presented in a rather esoteric fashion. Not to mention,
| actually leveraging those concepts in is bad practice
| anymore, i.e., using a pointer arithmetic to loop over
| arrays instead of iterators or the like.
|
| I didn't grok a lot of those concepts until I took computer
| architecture, which was taught in assembly language. And we
| weren't taught x86, but a toy assembly language designed
| for teaching.
|
| Another big pain point I had in school is that every
| professor / TA had different opinions on what was a right
| and wrong way of doing things in C++. And sometimes their
| opinions would conflict with the damn documentation too.
| There's nothing like having to relearn core language
| concepts every year at the whims of professors. This is
| probably where most of my disdain for the language has come
| from.
| zabzonk wrote:
| the chance of you being taught correctly by your so-
| called "professors" (they are not professors unless they
| have been appointed to a chair) is vanishingly remote,
| but this has zero to do with the language
| kingaillas wrote:
| >However, there is value in learning some of the under the
| hood concepts such as
|
| >[...]
|
| >I don't think schools need to teach employable
|
| My University taught the intro CS class in Scheme; years
| after I graduated they switched to Java and last I saw it
| was Python (based on visits back to campus and wandering
| through the bookstore to see what textbooks were for sale).
| I just checked and it still Python, based on the course
| description ("how to design and implement algorithmic
| solutions in Python"). I see a few 2xx level classes are in
| Java, and after that it stops mentioning specific
| languages.
|
| Anyway, it's tough since there is pressure to teach the
| concepts, which argues for certain languages, yet also
| produce employable graduates, which argues for certain
| other languages.
|
| Finding overlap is tricky... teaching theory in Haskell,
| under-the-hood concepts in assembly, software development
| gluing libraries together in javascript/c++, may in fact be
| the superior approach... but there is fatigue associated
| with learning languages just to learn more languages when
| maybe a nice general language that serves many educational
| needs is a better way.
|
| Python might be the sweet spot to start out with, and
| indeed it looks like the 3 intro classes at my alma mater,
| are taught in Python. I'd like to think the driving force
| behind this is that 1) Python works well, and 2)using one
| language for first year students (well, 2nd semester 1st
| year or perhaps 1st semester 2nd year) lowers the mental
| overhead on the students.
|
| Going heavy on C/C++ early essentially selects people that
| already come in with a programming background. Some folks
| don't get that, or not much of it, in high school and want
| to enter the field anyway. And I think it is fair for them
| to reasonably expect, like you can with every other
| academic field, that they can do that via the starting
| curriculum.
| int_19h wrote:
| C and C++ are still horrible languages even if you want to
| teach those concepts, because of how many footguns they
| have. That's why Pascal was so popular as a teaching
| language, historically speaking - it still has pointers and
| other stuff you need for manual memory management, but it's
| much simpler and more regular both syntactically and
| semantically.
| zabzonk wrote:
| no, it has exactly the same issues as c and c++, and some
| of its own, such as arrays of different sizes being
| different types. guess why it isn't used anymore
| mkl95 wrote:
| 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.
| datalopers wrote:
| C++ doesn't require you attend an annual furry convention.
| sebstefan wrote:
| Uh, yes? The fursona just has to wear a white shirt.
| twic wrote:
| Real talk though, the only furry i know (that i _know_ i
| know), i know from a C++ Slack.
| Karsteski wrote:
| Annual furry convention might be fun though wdym
| brink wrote:
| Or be a part of a discord group that flies a pride flag in
| your face for 6 months of the year. A helping of ideology is
| what I've really been looking for in a programming language.
| sebstefan wrote:
| Oh no, not a _pride flag_
| giraffe_lady wrote:
| wow sounds rough buddy
| brink wrote:
| May not be rough for me, but it's rough for @ChoooCole.
| You're being dismissive, acting like the ideology is
| harmless. She has to live with the consequences of the
| actions that the pride community influenced her to take
| at 16. It's not harmless.
| giraffe_lady wrote:
| yes it is lol
| sk1pper wrote:
| Hmm, I think that's a little heavy-handed. Just off the top of
| my head: CUDA (maybe other gpgpu stuff too), gamedev, most
| projects with a UI. The tooling you'd be using in those spaces
| is still bleeding edge; too much so to use with a greenfield
| project that you intend to put in production, imo.
|
| I guess you said "in the coming decades," which might be true,
| but for the time being it's more than just niche libraries that
| might push one to use C++.
| justin66 wrote:
| > There's little reason to code a greenfield project in C++
| unless it involves leveraging some niche libraries,
|
| Wanting a GUI is not a "niche" concern.
| twic wrote:
| If you're writing a GUI app, you usually don't need the
| exceptional efficiency that is C++'s selling point, so you
| are probably better off using Swift or C#, instead of either
| C++ or Rust.
| ativzzz wrote:
| most desktop GUIs nowadays are written in JS because they run
| in browser or if they are desktop apps it's done via electron
| antegamisou wrote:
| Claims like these always reduce C++ to a systems programming
| language, neglecting the fact that is primarily used in
| computationally expensive projects in which Rust cannot be a
| valid substitute.
| clappski wrote:
| There's much more reason to do a greenfield project in C++ than
| Rust - experienced C++ hiring is still considerably easier! Not
| everything has a purely technical motivator.
| mkl95 wrote:
| I'd say the trend in the industry is to hire engineers rather
| than language specialists. An experienced C++ guy should be
| able to learn the Rust basics in a few months.
| nicoburns wrote:
| > experienced C++ hiring is still considerably easier
|
| Perhaps, but you can take experienced devs with a background
| in other languages and expect them to write solid Rust code.
| You probably only need to hire 1 or 2 people who already know
| Rust.
| thorin wrote:
| I don't know any people who program in Rust. I've been
| programming 25 years professionally. On my LinkedIn and
| through friends I probably know 50 people who do c++
| programming in some capacity, including myself, to a poor
| level.
| nicoburns wrote:
| As someone who only knows C++ to a poor level, you're
| exactly the sort of person I wouldn't want to hire for a
| C++ job, but I would consider hiring for a Rust job. The
| bar is way higher for C++ because it's so easy for even
| experienced developers to introduce mistakes.
| gridspy wrote:
| Perhaps you should be the first in your group? ;)
| alkonaut wrote:
| I'd be tempted to pick Rust for a greenfield project _even
| if_ I had only a team of C++ devs with no prior Rust
| experience. Having one person that can teach it would help,
| but it 's not an absolute necessity. And luckily every team
| has that one person ho is the Rust evangelist...
|
| If you can program C++ you'll pick upp Rust more quickly than
| any other convert. Unless it's a startup with a short runway
| where you might not have the luxury of a slower start, then I
| think it would probably pay of in both productivity, staff
| retention, ease of recruiting (later), and a lot of other
| parameters.
| mvuksano wrote:
| I wondered why C/C++ is not appreciated more by engineers. I hear
| a lot of comments along the lines "rust is safer". While I get it
| is safer in some aspects a lot of times I've heard people end up
| writing unsafe rust anyways. Then the next argument goes well you
| should write as little as possible of that unsafe rust. Fact of
| life is that you will need to write unsafe rust. Actually unsafe
| INSERT_ANY_LANGUAGE_HERE. My point is as an engineer you will
| need to learn how computer works. And I don't mean just at a
| surface level but really deep. So once you have that knowledge
| why not just use it?
| crims0n wrote:
| I agree for C. It's simple, it's fast, it's portable, and it's
| a fantastic gateway into ASM. To your point, I believe learning
| it is an important part of foundational computer science - and
| for that reason I don't think it will ever go away completely.
|
| C++ on the other hand...
| rychco wrote:
| 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 install libraries,
| different C++ standard features supported, etc.
|
| I like C++, and tooling has come a long way, but it's so much
| easier to download rust/Python/node and you're basically set on
| every platform & immediately ready to go. NOW consider pay, and
| even someone enthusiastic about programming C++ will reconsider.
| aliqot wrote:
| > 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!
| spoils19 wrote:
| This comment doesn't really align with the HN guidelines.
| teg4n_ wrote:
| Neither does yours (or mine).
| m463 wrote:
| I find python such a pleasure in comparison. I can express
| myself so easily.
| germandiago wrote:
| True. I also like Python.
|
| The problem is when you need 30 servers instead of one to
| manage your load, though, lol.
| chaostheory wrote:
| I also love Python the language, but it's hard to keep
| using it when it's so slow. Parallel processing helps, it's
| still slow. Definitely dumping pandas the first chance I
| get. It's one of two major bottlenecks with the other being
| anaconda for Windows. Maybe the culprit is running Python
| on Windows since it relies on so many parts of nix?
| intelVISA wrote:
| As a C++ enjoyer I would 100% have learned Rust if it was
| around when I started... just for Cargo alone.
|
| Problem is now I've already done my time in the Makefile
| trenches there's little incentive in me re-learning another
| systems lang and having to compete with lots of smarter people,
| with more Rust exp, for jobs whilst giving up all my arcane
| knowledge of CMake and friends.
|
| Rust being popular atm is great for C++ if I'm honest as it
| siphons away a new gen of systems programmers over to another
| lang allowing me to sell my dark services for more coins.
| [deleted]
| larsrc wrote:
| I did my time in the Makefile trenches, too. I'm happy that
| I've learned other languages. There will always be smarter
| people than you, but you will bring your particular knowledge
| and do new things. Keep on learning!
| chaostheory wrote:
| I wonder how the Cobol market is doing?
| StreamBright wrote:
| The incentive is to do it for the greater good. For a safer,
| better future.
| jupp0r wrote:
| 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++.
| deviantbit wrote:
| 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.
| pencilguin wrote:
| Template metaprogramming is hardly ever needed anymore.
| C++20 has better built-in features that for most of what
| was done with it, that compile much faster.
|
| _Almost all_ C++ programmers completely ignore it. You can
| too.
| commandlinefan wrote:
| > have best practices in place that are now considered
| antipatterns
|
| Like using C++ you mean?
| jupp0r wrote:
| C++ is a tool and it still has its use. If you have ever
| tried to slowly sprinkle Rust into a large C++ code base
| you will know that it's hard, laborious and error-prone.
| For completely new projects that don't need existing C++
| libraries: sure, I wouldn't use C++ nowadays. There's tons
| of good reasons that lots of actively developed code is
| still C++ though.
| astrange wrote:
| 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<int>` in C++. Do they just like hitting
| keys on the keyboard?
| germandiago wrote:
| > I'm still wondering why `(int)` is spelled
| `reinterpret_cast<int>` in C++
|
| 1. because it is greppable and unsafe
|
| 2. because there is also static_cast and dynamic_cast
|
| 3. Because in C (int) is all three _at once_ and not
| greppable - > C will let you do whatever, C++ will not let
| you do with a static_cast everything you can do with a (T)
| cast.
|
| All in all, it is nice to ask, but if you do not know what
| you are talking about except for the surface, then, you
| should not say:
|
| > Do they just like hitting keys on the keyboard?
|
| No, we do not, but we hate even more to get an ungreppable,
| undecipherable (semantically) casting lost somewhere in
| several tens of thousands of lines of code :) This eases
| finding the suspicious code more easily.
| jupp0r wrote:
| > I'm still wondering why `(int)` is spelled
| `reinterpret_cast<int>` in C++. Do they just like hitting
| keys on the keyboard?
|
| They are doing different things. For example,
| `reinterpret_cast<int>` cannot cast away constness but
| `(int)` can. There are other differences and you should
| never use C-style casts. In most C++ code bases I worked
| on, there were static code analysis checks pre merge that
| would prevent anybody from merging code with C-style casts
| to master for that reason.
| strangattractor wrote:
| %90 of what people do today is import some open source library
| or package to do the heavy lifting and weave them into an app
| using a scripting language. It is sort of the MS Basic approach
| of the web app world. Nothing wrong with that. C++ is used for
| a different class of problems that are not the main focus of
| the industry anymore. I would likely choose something like Rust
| today but at the time C++'s star was rising there really
| weren't a lot of other better options.
| ayberk wrote:
| As someone who has been writing C++ at Google, this exactly.
| Despite all the tooling, guidelines and "internal magic", C++
| is still an abomination. And no it has nothing to do with
| memory management, I actually do like C.
|
| I love how Eric Raymond describes it as "anti-compact",
| because, well, it really is. C++ as a whole should be
| deprecated -- and no new projects should use C++ (unless for
| some very odd and specific reason).
| jeffreyrogers wrote:
| > 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).
| dthul wrote:
| 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.
| cmollis wrote:
| 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.
| cmollis wrote:
| oh and the last time I wrote in C++, I was using gmake..
| all those compiler and linker switches.. header and
| linker search paths.. ugh.. I felt like I was launching a
| rocket to the moon just getting some of that to build.
| don't miss that.. chasing down memory corruption in
| threads with gdb.. also painful. I get that C++ is much
| better now, but I haven't really used it in a long time
| so can't comment.
| germandiago wrote:
| 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.
| dthul wrote:
| Sure, but I wouldn't say that's easy.
| ayberk wrote:
| 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.
| jeffreyrogers wrote:
| C++ has improved a lot over the past decade or so.
| Compilers can add runtime checks now that make most
| memory bugs easy to detect and diagnose. C++ has plenty
| of warts and legacy stuff that you wouldn't keep if you
| were designing a language from scratch, but it is way
| better than it used to be and there still isn't anything
| that fills the same space C++ targets. Rust tries to but
| IMO it is too opinionated.
| bjourne wrote:
| > It _looks_ easier to me because it lets me do anything
| I want. C++ makes me feel like I'm going faster, but then
| I spend two weeks debugging a weird memory issue.
|
| FTFY!
| germandiago wrote:
| > 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.
| germandiago wrote:
| > C++ as a whole should be deprecated -- and no new projects
| should use C++ (unless for some very odd and specific reason)
|
| Too bold statement. There are still lots of reasons to keep
| using C++. LOTS.
| gort19 wrote:
| DeathArrow wrote:
| >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.
| rychco wrote:
| Mark Russinovich (of Sysinternals fame), thinks Rust should
| be the non-GC language of choice moving forward.
|
| https://twitter.com/markrussinovich/status/1571995117233504
| 2...
| jeffreyrogers wrote:
| If people think C++ is hard to learn and attracts
| opinionated people boy are they in for a surprise when
| they start using Rust.
| josephg wrote:
| Learning rust is like cycling over 2 big hills. It's
| exhausting and painful if you're in any way out of shape.
|
| Learning C++ is like cycling from SF to LA. It starts
| easy enough and every day you're making a lot of
| satisfying progress. But you have so far to go because of
| all the features and quirks of the language.
|
| It's probably easier to get started learning C++. But
| it's also much faster to finish learning rust and be able
| to read almost all rust code. (Pin still scares me
| though)
| Cyph0n wrote:
| I like the analogy!
|
| I'm still not comfortable with Pin, UnsafeCell, raw FFI
| (lifetime and ownership handling across the boundary is
| tricky), and complex macros. But I also think that you
| don't need to understand these at all to be an effective
| Rust dev.
| tele_ski wrote:
| I like you're analogy, but I do think there are features
| of c++ that are big hills as well. To me it would be SF
| to LA with some big ups and downs on that long ride.
|
| I'm also curious what's difficult about pin in rust? It
| basically just disables moving of the object for the
| lifetime of the pin.
| larsrc wrote:
| You forgot to mention that someone mined parts of the
| roads from SF to LA.
| bdavisx wrote:
| More like NY to SF. The Appalachians would be when you're
| first learning pointers and the Rockies would be about
| the time you hit the STL and friends.
| jeffreyrogers wrote:
| You have to learn pointers in Rust too and I don't think
| the STL is any more complicated than Rust's standard
| library.
| zozbot234 wrote:
| Rust is _way_ easier to learn than C++.
| primeblue wrote:
| [deleted]
| germandiago wrote:
| I do not think so, though.
| adgjlsfhk1 wrote:
| Julia is solving many of the same problems as C++. GPU
| compute, HPC, high performance algebra kernels are all well
| within Julia's purview. It's not (at least yet) good for
| things like writing OS kernels but there is a large amount
| of overlap with C++.
| programmer_dude wrote:
| Isn't Julia a dynamically typed language?
| littlestymaar wrote:
| > Rust? It's much more painful to use than C++.
|
| Unless you're doing something really highly specific to C++
| (like Cuda for instance or deep integration with big C++
| codebase), saying that rust is _painful_ compared to C++ is
| laughable.
| intelVISA wrote:
| Gonna have to unwrap() this take
| yoyohello13 wrote:
| I'll just ignore this take and let it become a problem
| later.
| jjav wrote:
| > And what can be used instead of C++?
|
| For most use cases Java is a better option. Very fast,
| without any of the pain.
|
| If you truly must not have a VM (rare), there's still C.
| Perhaps rust.
| dtx1 wrote:
| > Rust? It's much more painful to use than C++
|
| Write a sufficiently complex memory safe program in C++. I
| dare you. It's been proven again and again that humans
| can't do it. And calling Rust more painful than C++ is just
| absurd.
| smackeyacky wrote:
| I don't think that's true. I started C++ using the 'cfront'
| system, the major push wasn't because C was somehow
| lacking, it was because it was fashionable to do object
| orient programming which is _hard_ in C. Various horrible
| patterns were invented using function pointers so C
| programmers could feel like they were doing object oriented
| programming and all of them sucked.
|
| When cfront turned up, the first versions basically
| automated that suckage. C++ did get better, but it was
| still horrible compared to CLOS or Smalltalk. This was
| largely due to weirdness in how the constructor/destructor
| ordering worked, the giant bogosity that is multiple
| inheritance and a few massive other undefined behaviours
| that every compiler did differently, but I think at this
| point it's fair to point out the language is bad and things
| like C# are so much better it's not even funny any more.
| thrwyoilarticle wrote:
| IME the nature of C++ attracts smug trivia experts more than
| typical softeng. Skilled, yes, but unhelpful.
| j-krieger wrote:
| 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 this a feature).
|
| Tooling is even worse.
| greyman wrote:
| I coded in C++ professionally for about 15 years and don't
| remember it would be "incredibly daunting". Not easy, but
| doable. But yes, I also exited the pool, now I work in Golang
| and just wouldn't go back to C++.
| codalan wrote:
| 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.
| jdlyga wrote:
| Personally, I would love to work in c++. It's my favorite
| language to work in. I have over a decade of experience with it
| professionally. But, seems like most jobs these days are python.
| Animats wrote:
| Ah, employer thinking. There should be a "pool" of available C++
| programmers. Not that they should hire reasonably good
| programmers and train them in C++.
| Clobbersmith wrote:
| I've done a little bit of C++ in the last couple of years.
| Compared to pretty much any other common language out there the
| developer experience is full of pain. I can program C++ but why
| would I want to?
| VMG wrote:
| that should raise the salary on the market, not lower it
| Hatrix wrote:
| A job description might say C++ at the top but, it will be
| followed with a page of other requirements and weeks of
| interviews. They won't hire you unless you are already doing
| everything.
| wojciii wrote:
| I spent some time developing i c++ 10 years back or so. I really
| don't want to use OOP. I fucking hate OOP. No amount of money
| will make my use C++ again.
|
| These days I do embedded programming in C with some Python on the
| side. As a plus the nightmares about debugging c++ code
| disappeared.
| lordleft wrote:
| Looks like C++ developers / holdouts will be commanding 400-600k
| salaries in the comming decades, like those arcane COBOL wizards
| still tinkering on banking mainframes.
| ryandrake wrote:
| This is literally my career wind-down/retirement plan. I'll be
| 62 when the Year-2038 problem hits, and they're going to need
| to overturn some rocks to find C and C++ systems programmers
| who still can read from a monitor.
| c54 wrote:
| Lmao "read from a monitor" as instead of from whatever fancy
| ARVR dev environments we'll be on in 15 years?
| smolder wrote:
| I could see AR/VR dev environments being viable enough to
| not get laughed at in 15 years, but there's no way we give
| up 2D displays in the majority by that time.
| gridspy wrote:
| In 15 years? Potentially we'll have brain interfaces by
| then. Just imagine the job you want done and you'll "see"
| in your mind's eye the existing solutions in your code-
| base and then on the (contemporary version of the)
| internet.
| _dain_ wrote:
| don't kid yourself, those brain interfaces will be
| emulating 80-character width terminals
| psychlops wrote:
| Indeed, if they can get one of the few jobs that frees up every
| few years.
| 3pt14159 wrote:
| But why?
|
| Why not be an proficient Python developer and make the same
| compensation[0] with better docs, better libraries, better
| codebases, no compilation annoyances[1], easier to read code,
| and fewer not-defined-by-the-spec weirdness?
|
| C++ would have to pay 4x what Python pays for me to even
| consider doing it again. It literally makes me sad when I write
| software in it. Especially the libraries.
|
| [0] Mid-six digits as an IC is very doable in North America.
|
| [1] If you want to count the occasional Cython thing, fine.
| Almost no compilation annoyances.
| eddsh1994 wrote:
| > Mid-six digits as an IC is very doable in North America.
|
| No, it's not. Some people who read this comment probably do
| make that, and it's great, but it's not the norm. You have to
| be _exceptional_ to get there.
| 3pt14159 wrote:
| I've been there?
|
| It's very doable and far easier than understanding C++ in
| my opinion.
| eddsh1994 wrote:
| > Mid-six digits
|
| Do you mean $500k? On levels.fyi for San Francisco you're
| talking about the 95% percentile of people who upload
| their salaries (which tends to the higher range anyway),
| and that's mostly stocks. So in the highest paying part
| of North America, at the highest paying companies where
| employees put their salaries on levels.fyi, a small
| minority can reach $500k. North America as a whole? Nope.
| didgetmaster wrote:
| C++ is my favorite language. When I started my 'side project' (a
| new kind of data management system called Didgets) I used it
| exclusively.
|
| Before I semi-retired to work on the project full-time, I would
| sometimes check out the help-wanted postings for various software
| companies. It became more and more rare to see a job posting that
| focused on C++ skills. Systems level programming and being able
| to write very performant code does not seem to be nearly as high
| a priority today.
| cmrdporcupine wrote:
| There's lots of C++ programmers out there. But they're bottled up
| in FAANG, I think. So you have to be able to compete with that.
|
| Working at Google is on the whole a _lot_ of C++. Major parts are
| moving to Go, certainly. But there 's absolutely giant code-bases
| of pretty cleanly written C++ services, and most Googlers are
| quite proficient in it and there's whole teams at Google that
| work on improving C++ standards and techniques etc etc etc. Not
| to mention the Chromium codebase as well, which I also worked in.
| I get the impression this is also a thing at Facebook.
|
| All of this to say: if you want C++ programmers, you need to pay
| competitive enough rates to pull them away from there.
|
| (That said, if you're hiring for C++, I'm looking.. and I don't
| expect a Google salary, just a fair one. I'm not the most elite
| C++ programmer in the world, but I can write good code and
| understand your system...)
| scruple wrote:
| > But they're bottled up in FAANG, I think.
|
| Quite a few of them are locked up by AAA games studios, at
| least the ones that I personally know.
| ChrisMarshallNY wrote:
| From what I understand, Google is really about a crippled
| subset of C++, that people jokingly call "C+-".
|
| I ran a C++ shop for 25 years. I used to program in it, but
| stopped, many moons ago. The new C++ is a _huge_ change from
| what I knew.
|
| I am expecting to see a lot of hate for the language, in this
| thread.
|
| Regardless, it is a _very_ powerful language, and it is not for
| the faint of heart.
|
| I attended a Swift conference, many moons ago, and one of the
| speakers was this wonderful woman that had recently moved to
| Adobe (a C++ shop).
|
| She was supposed to speak about Swift, but ended up speaking
| about C++, and the wonderful, supportive community of older,
| experienced developers she found, around the language.
|
| I loved it, but I'll bet a lot of the folks around me, were
| squirming.
| jupp0r wrote:
| "From what I understand, Google is really about a crippled
| subset of C++, that people jokingly call "C+-"."
|
| Chrome is pretty good at using modern C++ FWIW.
| orwin wrote:
| Ah! "C+-" is what i called Golang when i first tried it
| around 2014-2015. I guess i can see where some ideas came
| from.
|
| (Still a very good language if you know what to do with it)
| maxloh wrote:
| Did they upload the recording to YouTube? I would like to
| listen to her.
| ChrisMarshallNY wrote:
| It was try!Swift New York, back in 2017, or so. I don't
| think they published vids, but maybe. I'll have to go look
| at my badge, to see which one it is.
|
| https://www.tryswift.co
|
| _[UPDATE] It was 2019. They have videos, but hers (and a
| few others) aren 't there._
|
| _[UPDATE 2] Found it. It isn 't linked from the main site,
| but is on the YouTube playlist:
| https://www.youtube.com/watch?v=CZOVnlwWPZk_
|
| It's a really good talk. I like her attitude.
|
| This is her: https://www.savinola.com
| pradn wrote:
| It's hardly "crippled". I find myself quite productive
| writing C++ at Google.
|
| Take a look at the style guide yourself. I think it's
| pragmatic.
|
| https://google.github.io/styleguide/cppguide.html
| cmrdporcupine wrote:
| All sane C++ codebases must use a defined subset of the
| language. Google's is one that works for them, with some
| pretty strong standardization. It's a good set of
| compromises. But you won't get far programming in it if you
| don't know the broader semantics of the language.
|
| I didn't do C++ from about 2003 to 2013. When I came back I
| was _delighted_. It 's so much better.
| VHRanger wrote:
| If only unique_ptr makes the whole experience so much
| better
| ChrisMarshallNY wrote:
| I liken C++ (and other "industrial" languages, like PHP),
| to "advanced" tools, like the specialty tools and brands,
| that only professional mechanics know, like OTC. You won't
| get them at Home Depot.
|
| The language definitely has its niche, and I am glad to see
| it not being used for standard GUI programming, anymore.
|
| But for that niche, there's nothing better, and it's a big
| niche.
| TremendousJudge wrote:
| What can PHP do that other less vilified languages can't?
| What is its "niche"?
| gridspy wrote:
| My experience from 1990 was it was the perfect language
| to add a bit of server-side logic to some raw HTML.
|
| So the niche (for me) was a nice transition from
| something I understood (HTML) to something new (dynamic
| webpages).
|
| In that way it is similar to batch files / bash scripts.
| ChrisMarshallNY wrote:
| Please, everyone is supposed to be slagging C++ (and me),
| here. I'm sure there will be rich opportunities to dis
| PHP, in other threads.
| TremendousJudge wrote:
| You are right, my apologies. It was just so surprising a
| mention I couldn't stop myself.
| UncleMeat wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| UncleMeat wrote:
| The style guide is publicly available:
| https://google.github.io/styleguide/cppguide.html
|
| I've never heard anything remotely similar to "avoid
| objects" here.
| ChrisMarshallNY wrote:
| Well, this was back in the C++ 11 days.
|
| No biggie. Won't get in a fight about it.
|
| Have a great day!
| UncleMeat wrote:
| 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).
| cmrdporcupine wrote:
| Yeah. If anything the Chromium codebase is bloated with
| uncomfortably intricate OO patterns. Google3, less so,
| but that's because that kind of server-stuff doesn't lend
| itself to the same kind of thing, maybe.
|
| I like the Google style guide overall. I tend to use it
| on new projects even though I'm not there anymore, and
| when I get into other people's code often my first
| instinct is to "clean it up" into that style :-)
| dvirsky wrote:
| 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.
| ChrisMarshallNY wrote:
| 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/TaligentDoc
| s/TaligentOnline/DocumentRoo...
| UncleMeat wrote:
| "Don't use pointers" was definitely never in the style
| guide.
| kabdib wrote:
| C+- is pretty common. I last read the Google C++ guidelines
| maybe ten years ago. They were pretty much in line with the
| decisions that other large C++ projects I've worked on had
| made, like we all encountered the same footguns and language
| misfeatures.
|
| Every 5-10 years there's a big shakeup and the C++ culture
| _changes_ , but it takes a long time for things to filter
| down into the embedded world (for instance).
| wnolens wrote:
| MSFT was the same (at least the corner of it that I knew). We
| called it "C, with classes".
|
| I never apply to C++ jobs despite those 6 years of experience
| because I think my knowledge there is stuck in 1999 and I
| have no idea about the STL.
| sqeaky wrote:
| Learning the language fundamentals robustly is the hard
| part, and everyone has incomplete knowledge. The C++
| standard library is easy to learn for someone in your
| position. If you want to, start with something like
| iterator pairs and few trial problems, it will feel just
| like pointer arithmetic then the standard algorithms will
| be easy.
|
| I have tried to focus on C++ during my career and I still
| haven't even touched ranges or needed about half the std
| algorithms.
| hardlianotion wrote:
| Ranges are a little frustrating, they aren't uniformly
| implemented across the commonly used compilers.
| Analemma_ wrote:
| There are only two types of C++ shops: the ones that use a
| rigorously-enforced subset of it, and the ones where the
| codebase is an impenetrable hornet's nest. You _must_ decide
| on a subset of C++ to use or you 'll go insane. Google made
| some opinionated choices and tradeoffs about which subset to
| use (as did Microsoft and every other company with a huge C++
| codebase), and it's possible to disagree with the specific
| boundaries they chose, but the mere fact that they chose to
| do this is unimpeachable.
| mooreds wrote:
| > 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 labor shortage that
| salary can't solve". It may take some time (as people get
| trained up) but employers complaining about talent pool issues
| but paying get little sympathy from me.
|
| For example, from a link in the article, consider this job
| https://www.efinancialcareers.co.uk/jobs-UK-London-C_Develop...
|
| 150k pounds for a job in London that is a tech lead position
| seem low to me.
| bearmode wrote:
| UK salaries on the whole are shockingly poor. That's actually
| a really decent salary here. Devs can start anywhere from
| PS20k to PS35k depending on background/where in the country
| you are.
| twic wrote:
| 150k plus bonus. It's at a quant firm, so the bonus is likely
| to be ~50% of base salary if you do okay, and multiples of
| that if you do great.
| pyb wrote:
| Maybe, but C++ developers who haven't worked at hedge funds
| before wouldn't know it from this advert, and probably
| won't apply.
| twic wrote:
| Perhaps. I note that position is being advertised by
| Oxford Knight, a high-touch recruitment firm. Their main
| modus operandi is to make contact with someone looking
| for a job, find out what they are looking for, and then
| suggest particular openings on their books to them; they
| would have plenty of opportunity to explain about the
| compensation. I think these public job listings are a bit
| of a cheap additional thing, and aren't that important to
| them.
| pyb wrote:
| As a C++ developer hoping to move back to London, this
| side of the market is still very opaque.
| bambataa wrote:
| What are hours like at HFs and quant firms? I've heard they
| can be bad.
| 22SAS wrote:
| That's another load of BS spread by people not in the
| industry. They equate HFT's and quantitative hedge funds
| the same as investment banks. At most HFT's, mine
| included, devs are mostly doing 40-45 hours a week. Some
| places like Citadel, Headlands, the work hours are
| terrible (still not IB level bad), but the rest of the
| places it varies between 40-50.
| mooreds wrote:
| Thanks, that's fair. I've never worked in the finance
| space, so didn't know that. TIL!
| BeetleB wrote:
| > 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 enough
| revenue to pay such salaries".
|
| Try living in countries with very different economies (1st
| world, 3rd world, etc) and this becomes obvious. You'll see
| jobs in one country that simply cannot exist in another.
| YetAnotherNick wrote:
| > 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.
| BeetleB wrote:
| > 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.
| hiq wrote:
| > It's fair to call that a labor shortage in the
| transition period.
|
| I don't know about fair, but I find it misleading. When I
| hear "labor shortage", my intuition is that just having
| more people around (Advertise job offers better? Give
| more work permits?) would solve it, not that the market
| is such that this type of work doesn't make financial
| sense anymore.
|
| "Labor shortage" sounds like some macroeconomic temporary
| situation to which businesses shouldn't need to adapt to
| beyond temporary measures, while what you're describing
| seems like a failure from a business to adapt to a new
| stable situation.
| mywittyname wrote:
| > The labor analogy for me is "there's no labor shortage that
| salary can't solve".
|
| Assuming the labor you need is fungible.
|
| For a sandwich shop, raising pay will probably solve a labor
| shortage. But even salaries of $10,000,000 a year won't
| produce more surgeons. It might inspire more people to get
| into the pipeline, but that's a 10-15 year lag.
| gridspy wrote:
| There might be a 10 year lag creating more surgeons from
| scratch, but you'll have existing surgeons suddenly working
| for your company today.
|
| Your 10-15 year lag assumes untrained workers. You'll have
| a stream of people transitioning from other medical
| professions or surgical specialisations to your $10mm job
| category, many of whom require much less than 10 years of
| additional training (1-2 years? on the job?).
| TheCoelacanth wrote:
| It will solve the shortage by allocating labor to the most
| economically valuable uses.
|
| If you can't find developers at the price you can afford to
| pay, then make do with fewer devs, raise your prices or go
| out of business. The market doesn't owe it to you to make
| your business model profitable.
| efficax wrote:
| Although the pound has recently crashed, the general rule for
| comparing UK salaries to US ones is to 1.5x it to dollars. A
| PS150k salary in London is equiv to a ~$200-250k salary in
| the US. Not bad, I'd say.
| thrown_22 wrote:
| >~$200-250k salary in the US. Not bad, I'd say.
|
| In SF or NYC? For a junior dev who can maybe write a for
| loop without supervision sure.
| giobox wrote:
| 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.
| _dain_ wrote:
| >While it's of course good by local UK standards
|
| understatement, PS150k is outstanding, london or
| otherwise
| mooreds wrote:
| That's fair, I was using 1:1, even though London is
| surprisingly cheaper than Denver, CO (according to the cost
| of living website I found).
| eddsh1994 wrote:
| London can be as expensive or cheap as you want it to be.
| I worked for a startup on 23k when I first started
| working and my now wife was an undergrad, we still had a
| studio in Central London (zone 1). On the other hand you
| can have a town house in Belgravia for prices similar to
| Atherton.
| forgotusername6 wrote:
| 160k puts you in the top 1% of UK earners. With bonus that
| job is comfortably in that bracket. UK salaries are no where
| near US levels.
|
| Edit: my point is that a top 1% salary seems about right
| relatively for a tech lead position.
| KptMarchewa wrote:
| But sheiks and oligarchs are buying all the real estate, so
| the cost of living is pretty similar.
| forgotusername6 wrote:
| In central London perhaps. But it's by no means important
| to live actually in London and work in London. Commuter
| culture is (or at least was) big. Many people commute
| from the surrounding 100+ miles by train each morning and
| pocket those London salaries while living in low cost of
| living areas.
| _dain_ wrote:
| if you live in the fucking shard, maybe. london is
| expensive but let's not exaggerate: a PS150k earner is
| not worried about the cost of living.
| nottorp wrote:
| Which C++ anyway?
|
| Old one or the new one that looks like a lisp interpreter but at
| compile time? :)
| viig99 wrote:
| TBH high levels skills on C++-20 is not what these companies are
| looking for, instead on C++-14 or so, meanwhile anyone learning
| C++ in 2022 would rather want to pickup C++-20 ++ with its
| niceties, old C++ is too tiresome without extra rewards.
| orwin wrote:
| Well, it's quite easy:
|
| My brother actually likes C++ (and is probably better at it than
| most devs i worked with, even those writing a DB in C). He also
| is finishing school, and is searching for an internship. C++
| internship flat out don't pay enough. 600 euros/month. He is
| looking in a specific field in particular (audio and/or radio)
| and is currently expending to drones, so this might not help, but
| i find this crazy.
| jupp0r wrote:
| If this was true, salaries would be way up. Are they? Not from
| what I can tell. I recently switched to a web dev role and didn't
| have the impression that demand for my (imho considerable) C++
| skills was crazy high.
| dragontamer wrote:
| > However, only 9.3% of respondents used Rust at all and only
| 8.8% did so professionally. C++, meanwhile, languished at 48%.
|
| I mean... it sounds like there's a lot of C++ programmers?
|
| I guess the problem is that "talented" C++ programmers are rare.
| But... "talented programmers" in general are rare.
| cjg wrote:
| It's a poorly written sentence. The key idea is: "Rust got an
| 87% approval rate in the "most loved" category of the Stack
| Overflow Survey. [...] C++, meanwhile, languished at 48%"
| dragontamer wrote:
| Thanks.
|
| The number I was looking for was in a paragraph earlier, that
| I somehow missed when I made my post earlier
|
| > So where have all the C++ developers gone? The Stack
| Overflow Survey 2022 reported almost a drop of almost two
| percentage points in respondents this past year using C++
| (from 24.3% to 22.5%), even while the percentage of
| professional developers using it rose. The good news, though,
| is that 34.7% of respondents learning to code are using C++,
| placing it in the top 6 programming languages of that
| category.
| humanwhosits wrote:
| Employers just need to pay more, the devs will appear.
| LatteLazy wrote:
| There is no "pool"
|
| There is only a market.
|
| And the market, in it's perfect wisdom, will always supply
| exactly the correct number of talented C++ devs.
|
| If you cannot get one, it is because you are not willing to pay
| the market price.
| tlhunter wrote:
| > This was the consensus in a webinar from ProfitView, a crypto
| trading tools developer, on high frequency trading using C++.
|
| Maybe the discerning developer just doesn't want to enable the
| current snake oil fad.
| makemethrowaway wrote:
| Should I move away from c++ ? Anyone has done this? Everytime I
| try to do this I get dropped citing I lack "professional" webdev
| experience. Thanks in advance.
| UltraViolence wrote:
| I believe they're misguided to invest in C++. Enormous amounts of
| time and effort are spent solving weird pointer errors in C++
| programs which simply don't occur in other languages such as Rust
| and C#.
|
| Why is there this almost religious belief that their program
| needs the fastest execution time? It's madness IMHO. Trading a
| few percentage in performance for safety, reliability and
| security is more than worth it.
|
| I still use C++ on a very regular basis, but C# is my mainstay at
| the moment.
| spacemadness wrote:
| 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.
| UltraViolence wrote:
| 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.
| kyawzazaw wrote:
| But the origin of the article is from efinancialcareers.
| They are most definitely not gonna switch to Rust
| 22SAS wrote:
| Some HFT firms are starting to use Rust for new projects.
| spacemadness wrote:
| I was only addressing HFT as that was where the pleading by
| the author for more devs is coming from.
| einpoklum wrote:
| "eFinancial careers"? "ProfitView, a crypto trading tools
| developer"? "former software engineer at Barclays and Bank of
| America"? ... cry me a river.
|
| Maybe they're seeing less C++ developers because more of us
| developed a bit of a moral backbone and don't go working for
| those socially parasitic enterprises.
| spacemadness wrote:
| I believe it also entails unreasonable working hours like a lot
| of things in the financial world.
| rr808 wrote:
| I switched from C++ because the type of work is typically boring.
| Its either system level stuff, or HFT, usually some market data
| system or similar. Not to mention its likely a big old system
| with legacy code base.
|
| Seeing the salaries now I kinda regret switching out, but the
| companies and business problems you get in Python & Java are much
| more interesting.
| antegamisou wrote:
| > the type of work is typically boring.
|
| May be a personal taste thing but graphics programming,
| computer vision, scientific computing, robotics and even some
| embedded systems work is far from boring imo.
|
| But certainly the above are niche fields in a market where
| software engineering is almost always limited to webdev.
| gridspy wrote:
| Each of the industries you mention has a tech stack which
| must remain modern. That means that new work will migrate to
| the language easiest to do the work and find workers.
|
| It's gonna migrate away from C++ if C++ becomes "legacy."
|
| Embedded systems work is perhaps the exception - since there
| will be old hardware in the field. But firmware parts go out
| of production within 2-10 years and so new drivers require
| creation and new features encourage a migration to a whole
| new system.
| jbluepolarbear wrote:
| As a game developer I agree that a lot of C++ work can be
| really fun, but this less than 10% of what C++ is used for.
| More so you have databases, non-robotic embedded work, crypto
| (ew), systems work, etc. And they all pay terrible; except
| financial, but that's the most boring of all C++ work.
| volkk wrote:
| interesting. i've always found that the basic CRUD apps that
| most python jobs end up being are far more boring than HFT or
| systems level
| codegladiator wrote:
| The grass on the other side
| rr808 wrote:
| Yeah this is likely true. Its also some randomness if you
| end up on a good project & team or not.
| soinus wrote:
| As a personal anecdote, all of my jobs were actually very
| interesting with lots of interesting design problems spanning
| from low level systems to very high level design decisions.
| Granted I worked in automotive and later in AR and have been
| lucky enough to be at the start of some projects, but there
| definitely are interesting projects for C++ out there.
| zerr wrote:
| There is a sweet spot - desktop/GUI applications, but it's
| getting smaller and smaller, unfortunately.
| stavros wrote:
| The pool "running dry" would imply that you can't find talented
| C++ developers at any price. If that's not the case, you just
| aren't paying enough.
|
| The pool of jobs that will pay me $10m/year is also running dry,
| we really should do something about that.
| spacemadness wrote:
| The same has been said for embedded systems work while the jobs
| tend to pay 20-30% below webdev.
| hardwaregeek wrote:
| 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.
| Grinders wrote:
| It's all because of cryptocurrencies and the ongoing advancement
| of technology that making money has become more feasible. For me,
| the structure of earning while squandering time is ideal, and I
| enjoy https://rollercoin.com/bitcoin-faucet. Since I can play the
| games I want to play whenever I want and participate in earning
| cryptocurrency at the same time, this is really significant.
| PicassoCTs wrote:
| Is this a new type of SEO spam? Like you write a comment that
| gets upvoted, then change it at the last minute?
| jollyllama wrote:
| Part of the equation is that C++ devs just aren't as fungible as
| Python, Rust, and devs in newer languages (not that being a C++
| and a Python dev is mutually exclusive). The reason for this is
| that a lot of the C++ codebases were written before adoption of
| open source 3rd party libraries was widespread and codebases were
| more bespoke in general. So, as a consequence, the effectiveness
| of a C++ dev in any given org is highly correlated to tenure.
| It's tough to penetrate as a new dev, and if you have to move
| companies, it sets you back considerably. It's like a forest with
| poor soil and a mature canopy; difficult to take root in.
| tempxyz wrote:
| C++ is dead but as usual most of the industry lags behind.
| spacechild1 wrote:
| How exactly is C++ dead if it is widely used in the industry?
| rubyist5eva wrote:
| I should brush up on my C++...how's the pay looking? Ruby pays
| very well, which is my current bread and butter.
| adamius wrote:
| Is 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.
| pyb wrote:
| This. The gatekeeping can be intense : "must be proficient in
| C++ template metaprogramming", etc.
| 0xbadcafebee wrote:
| ....Excellent?
___________________________________________________________________
(page generated 2022-11-02 23:01 UTC)