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.
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.
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).
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).
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++.
As an older dev, screw those older devs that 'roast your code'.
The really good ones won't do that. The ones that do suffer from some weak superiority complex. I had three awesome mentors when I started writing C, and a couple great mentors when I did what little C++ work that I had to do.
The only scold I ever dealt with wrote overly wrought, overly complex crap. Kitchen sink patterns to handle any possible future variation, instead of solving the problem at hand.
Stay away from people like that, they'll just turn you into the same old grouch.
%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.
> 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
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++.
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.
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.
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.
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
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.
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.
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...)
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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++.
> 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.
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?
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.
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.
[+] [-] rychco|3 years ago|reply
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.
[+] [-] intelVISA|3 years ago|reply
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.
[+] [-] selfmodruntime|3 years ago|reply
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.
[+] [-] ayberk|3 years ago|reply
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).
[+] [-] jupp0r|3 years ago|reply
[+] [-] thrwyoilarticle|3 years ago|reply
[+] [-] greyhair|3 years ago|reply
The really good ones won't do that. The ones that do suffer from some weak superiority complex. I had three awesome mentors when I started writing C, and a couple great mentors when I did what little C++ work that I had to do.
The only scold I ever dealt with wrote overly wrought, overly complex crap. Kitchen sink patterns to handle any possible future variation, instead of solving the problem at hand.
Stay away from people like that, they'll just turn you into the same old grouch.
[+] [-] strangattractor|3 years ago|reply
[+] [-] m463|3 years ago|reply
[+] [-] aliqot|3 years ago|reply
Preach it!
[+] [-] sigi64|3 years ago|reply
[+] [-] thrwyoilarticle|3 years ago|reply
...I think I could last about 3 months in another language before I'd forgotten too much to go back.
[+] [-] martin1975|3 years ago|reply
[+] [-] keithnz|3 years ago|reply
[+] [-] primeblue|3 years ago|reply
[deleted]
[+] [-] npigrounet|3 years ago|reply
[deleted]
[+] [-] selfmodruntime|3 years ago|reply
[+] [-] gavinray|3 years ago|reply
- 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
[+] [-] magicloop|3 years ago|reply
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.
[+] [-] deaddabe|3 years ago|reply
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.
[+] [-] cmrdporcupine|3 years ago|reply
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...)
[+] [-] btilly|3 years ago|reply
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.
[+] [-] Kelteseth|3 years ago|reply
My personal experience: Universities (in Germany) simply stopped teaching C++. Most of it is now Python or C#.
[+] [-] lumost|3 years ago|reply
[+] [-] zaphar|3 years ago|reply
All told I would fine it more frustrating to work in C++ than enjoyable.
[+] [-] tannhaeuser|3 years ago|reply
[+] [-] stingraycharles|3 years ago|reply
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?
[+] [-] soinus|3 years ago|reply
[+] [-] hardware2win|3 years ago|reply
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|3 years ago|reply
[+] [-] rr808|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] soinus|3 years ago|reply
[+] [-] volkk|3 years ago|reply
[+] [-] zerr|3 years ago|reply
[+] [-] dsign|3 years ago|reply
[+] [-] rjzzleep|3 years ago|reply
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
[+] [-] nradov|3 years ago|reply
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.
[+] [-] lordleft|3 years ago|reply
[+] [-] ryandrake|3 years ago|reply
[+] [-] psychlops|3 years ago|reply
[+] [-] 3pt14159|3 years ago|reply
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.
[+] [-] codalan|3 years ago|reply
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.
[+] [-] ptero|3 years ago|reply
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.
[+] [-] VLM|3 years ago|reply
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.
[+] [-] kaizendad|3 years ago|reply
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++.
[+] [-] kibwen|3 years ago|reply
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.
[+] [-] Clobbersmith|3 years ago|reply
[+] [-] p0nce|3 years ago|reply
[+] [-] lpapez|3 years ago|reply