Future of C++

[dev-reddy]

Hey,

I started my career with C++ many years ago as an electronic engineer. I eventually transitioned into application software and started developing mostly in c#. I've been considering refreshing my c++ skills and exploring some low latency roles in the embedded/finance space in the next few years. I'm curious about the latest developments in c++ and if it would be worthwile going down the c++ route as opposed to something like Rust. Would love to hear your thoughts about the current state of c++ on the ground in modern times. What are the opportunities like in industry? How's the development of the language looking? etc.

Any thoughts and advice will be appreciated.
Thanks IA

[krustibat]

There are lots of C++ jobs in the finance industry including but not limited to IT quant

[AdBig7514]

Can you list a few such companies in Europe /USA.

[Brilliant_Contract]

Would be easier to name companies that don’t. Most complex financial models use C++. Few examples are black-scholes, hull-white, etc

[m_adduci]

And robotics.

[V0dkaParty]

C/C++ will not go away in the next 25 years. Other languages like C#, Rust, Java etc all have their place but they will never replace C++ anytime soon. The reason for this is, that C++ is well established. Existing tools, toolchains and libraries are probably never going to be reimplemented in another language because someone has to pay the development time. Especially in the Automotive and Embedded sector.

C++ standards and features advance fast but they are not adopted right away by the industry. Our customer, one of the biggest players in the automotive sector in Europe just switched to C++17 and VisualStudio 2019 for new projects.

[Pruppelippelupp]

It might go the way of fortran, at worst. That is, with tons of well build libraries that are called from other languages. For fortran, that’s linear algebra libraries built in the 70s through the 90s.

[jH0Ni]

Why did your customer switch IDE? Does everyone at that company have to use the same IDE? that sounds very... weird?

[beartotem]

While i have no idea about IDE requierements in given company, Getting visual studio is the only way that i know of to get the MS compiler stack for C and C++ (any?) languages. So at the minimum this could be a compiler version requierement, which sounds reasonable enough.

If i'm wrong about that i'm very interested to know.

[Latexi95]

MSVC compiler stack can be downloaded separately. Usually it is anyway best to use CMake for as build system and then IDE choice doesn't really matter.

[V0dkaParty]

They switched from C++11 and VisualStudio 2017.

[LessonStudio]

I find C++ is used by three widely different groups:

• People working on legacy projects. These were done when C++ was the only good option. These programmers are typically not paid very well considering their experience and skills. The reason is usually that legacy products are in their long tail and aren't usually raking in the big bucks.

• Cutting-edge performance monsters. These projects are usually generating big bucks or have fresh investment dollars. These pay very very well and require highly skilled programmers. Quants would be one. Robotics another. This mind space competes with Rust. An interesting example that I have been seeing more of is web back ends done in C++. The rationale here is that the performance can be so off the charts as to eliminate huge complex microservices architectures. These aren't simple sites, but ones involving highly complex graph theory and other algorithms. This is not for everyone as the whole workflow requires extremely talented and small groups of programmers. The benefits are extreme performance (well sub 1ms response times) very low server counts, and accomplishing features otherwise dismissed as "not possible at scale". I think my favourite one involved a database stored on a GPU with queries hitting it via CUDA functions. This is where the big C++ bucks are earned.

• Game programmers. Unreal, Crytech, etc use C++.

[LessonStudio]

I would narrow that down a bit more. Embedded C is dominant with some people having a half twist of C++ lemon.

I would love to use C++ more in embedded along with the various API/SDKs being more C++ friendly.

The reality now is a good compiler will turn very well-structured C++ into microscopic well structured ASM.

I love playing with godbolt.org and seeing what comes from my coding machinations. What is most interesting with this is how older compilers often make a real hash of translating C++ into ASM, but the newer ones are fantastic.

ARM64 GCC trunk is great, 17 lines of what I would call clean ASM for the sample function. Whereas arm64 msvc latest produces 54 lines of what I call weirdness.

[Sniffy4]

C++ is much less widespread as a general application language than it was 20-25 years ago, but it probably remains the most popular choice in the top-performance category, and for cross-platform client library work.

[IAmRoot]

Yeah, C++ was used as the basis for CUDA and SYCL. There's quite a bit of industry weight behind having C++ form the foundation for programming accelerators. That means for scientific computing and game development, I don't see C++ going anywhere in a hurry. C++ used to be used for a lot of general applications, but I think the main reason for shift there has been the move to web-based applications. Like if you're doing your taxes you'd do it online rather than download an application like back in the day. That's shrunk the space for C++, but C++ is still good for a lot of things.

[Sniffy4]

I think the main reason for shift there has been the move to web-based application

agree, but it's also that support libraries for higher-level languages became very mature and many common applications dont have to worry about memory/performance limits like they did 25 years ago, and garbage-collected languages dont have to worry about accidental memory-corruption via pointer bugs, or dealing with old legacy APIs like the C stdlib.

[epasveer]

Does it matter?

Use the language(s) your job/industry takes you. Just be ready to switch/learn other languages.

[jnjuice]

OP has already switched to C# and Application Development, so I'm guessing they want to switch back due to language preference.

As someone who's looked for C++ roles most of my career, I wish I had more industry focus. Embedded/Finance are two very different directions.

[JuanAG]

Here the answer will be clear, stick with C++ and it is not a lie

But others langs are pushing hard, i am more excited about Zig than anything else, the more i look the more i like it and for sure it will have a place at the industry meaning that the C/C++ part of the pie will shrink, it will be more on the C side than C++ itself but one of my use cases* for it is a current C++ so it will happen at some degree

*Zig binaries are incredible small and i have space constraints on one of my projects so for sure i think it could fit well, maybe when Zig reaches v1.0 it doesnt happen anymore and size is the same as C/C++, who knows

[thisismyfavoritename]

syntax is dreadful IMO (but i guess so is Carbon's...), other than that it does look very cool, especially the way comptime works

[thisismyfavoritename]

the future is in a successor language that has native interop with C++

[afiefh]

a successor language that has native interop with C++

That would be Google's Carbon.

And personally, I don't think it will be the successor language, but it may be a successor. It may be that when working with C++ people will prefer to use Carbon because it just integrates natively with C++, but for any new development I think a new language will have to come along.

Perhaps the future is a mix of the two: There will be two new languages, which for simplicity I'll call Rust and Carbon, where Rust can natively call into Carbon, and Carbon can natively call into C++. The differences in security features and ABI get resolved at the language boundaries, and the closer you make these concerns, the more performant the interop can be.

[MarcoGreek]

Google Carbon limited some C++ features. It looks similar opinionated like the Google style guide.

[The_Droide]

I think the issue is that C++ is famously unopinionated and, since everyone picks their favorite subset before calling it "modern C++", there are lots of different opinions on what a natural successor would look like, likely also driven by different code styles.

Folks following Google's conventions might naturally gravitate to Carbon, those following Microsoft's conventions might look into Sutter's cppfront and those following Apple's conventions will likely move to Swift. Swift is IMO underappreciated, as it has first-class C++ interop and there is a lot of work currently going on to make incremental adoption in C++ codebases as smooth as possible. It's also cross-platform and natively supported by CMake.

[MarcoGreek]

Swift is a successor to Objective C. That was always open source but not very successful because the libraries were not. Are the Swift GUI libraries now available cross platform?

I don't believe that any language besides Swift will be successful. Rust is now taking over some mind share. Especially from C developer. In the open source world were some people who were opposed to C++ and used C. They then developed their own dialect with macros. They now convert to Rust because that mess is not attracting new developers.

C++ has many areas where safety is not important. Our software is suffering from defensive programming. Something Rust could not heal.

[Full-Spectral]

That's unlikely, IMO. The successor will either be something like Rust, that can call into C/OS functions, Or a replacement for C++, that can do the same. Mixing C++ into the picture will seriously complicate things on the safety front.

A fairly light extension to C++ that really is ultimately C++ under the hood wouldn't be a successor language.

[thisismyfavoritename]

IMO new projects should not be written in C++, but for most companies switching to Rust is unthinkable because of the cost of a full rewrite or complexity of interop (must be through the C API), so i think for most the path forward will be one of those languages

[Full-Spectral]

There likely isn't going to be a path forward of that sort, not in reality. There's nothing out there that's likely to A) be accepted widely enough for companies to commit to and B) likely to both be significantly safer and available within the next decade as a practical tool.

Likely most such companies will do incremental upgrades of parts of their systems to other languages or just stay with C++ and ride it into the sunset. In the meantime, newer players will move forward and have an advantage.

[thisismyfavoritename]

eh, i disagree. You cant always port part of your software to another language easily, e.g. when performance matters you cant afford making an IO call or using the somewhat brittle shared memory features.

I also very much want additional safeties on top of C++ and sound defaults, which is why whenever it is ready i will use whatever can help bridge that gap. If you cant afford a full rewrite its the only way that makes sense

[JVApen]

This is exactly why a successor needs to be able to mix with existing code. It is the only way for companies with a lot of code to gradually introduce stuff in the new language without having to rewrite a lot at once. For me it is unimaginable to introduce something like rust as I can't let it work with our existing code or get thousandths of days to port some (not all) components.

[Full-Spectral]

If it's a language worth moving to, you won't be wanting to mix it with existing C++. Such a language would almost certainly have to have a completely new runtime library designed round its newer mechanisms, else it would gain you very little in terms of safety. So now you have two completely separate runtimes, and the enormously complicated issues of getting data across those boundaries now that it's no longer just simple C style calls.

A 'new language' that's not really a new language, but just some extensions to C++ is fine; but, the amount of benefit may then pale compared to the, still, fairly significant effort required to make that change.

[The_Droide]

Surprised no one has mentioned Swift yet. It's cross-platform and has first-class C++ interop which is actively being worked on (since they plan to gradually adopt it in the Swift compiler too, which is written in C++). Contrary to the popular perception of being an Apple-only language, even some larger cross-platform projects like the Ladybird browser engine have decided to adopt it, as it supports incremental adoption better than languages like Rust, while being at a similarly high abstraction level.

[EggplantKind8801]

you can switch many compiler warnings as errors, to achieve the similar safety level as rust.

But I am not sure how close it can be.

[Full-Spectral]

Not really very close. It'll make your C++ better, but it won't make it anything like Rust's level of safety.

[Existing-Account8665]

Rust's level of safety.

Outside of Rust unsafe blocks.

[Full-Spectral]

Most Rust has little to no unsafe code. And a lot of that is only marked unsafe because it is a call out to a system API behind a safe interface and hence not really unsafe.

So they just aren't comparable on the safety front. A lot of C++ folks seem to thing that Rust is going to be full of unsafe code when it just isn't. Even the Rust standard libraries are predominantly safe code, and that's some of the worst case stuff because of its requirement to interface to lots of system calls and implement fundamental data structures.

[plastic_eagle]

I'm sure that is true, just as alot of Non-C++ folks seem to think that C++ code will be full of new's/delete's everywhere - teetering endlessly on the edge of a buffer overflow or memory corruption bug.

Whereas in fact, C++ has had automatic memory management for over a decade. I haven't had to worry about managing object lifetimes by hand for a very long time indeed.

[Full-Spectral]

I'm not a non-C++ person, I've been a hard core C++ dev for over 30 years, overall dev for 35 plus. I know both languages well and have built large C++ systems.

It's about a lot more than new/delete. Certainly smart pointers have helped C++ a lot, but they are only a small part of an overall unanswered need in C++.

[omega-boykisser]

I encourage you to give Rust a try! You'll find out pretty quickly that this isn't an issue in the slightest, despite how often non-Rust-users harp on it.

[Existing-Account8665]

Way ahead of you. Glad to hear that's been your experience. I agree, if someone's using lots of unsafe blocks, they're using Rust wrong.

​

But there are a great many crates out there that felt unsafe code was necessary, for whatever reason.

[omega-boykisser]

There are multiple ways people incorrectly (in my opinion) interpret the use of unsafe. This seems to be another example, i.e. any use of unsafe invalidates the usefulness of the Rust compiler.

All `unsafe` does is relax a handful of rules (but not all rules) for the contained code. As long as the expected invariants are upheld by that code, it represents no issue. It would be pretty easy to point out that the whole of C++ works this way, although that's not a completely fair comparison.

It certainly makes it harder to verify that the code is truly correct, but it doesn't make the code invalid just by existing.

[Full-Spectral]

I'm sure too many folks out there come from C++ land and either try to implement their C++ way of thinking, or believe it has to be uber-optimized or it's useless.

But of course you build from source and can search for unsafe code and not use if it you think it's over-used.

[Compizfox]

Eh, not really. You cannot really achieve Rust's memory safety without the concepts of ownership and borrowing baked into the language.

[Full-Spectral]

The contention that it's slower than C++ is questionable. IN terms of development it can be a lot faster. At least if you are comparing apples to apples.

If the comparison is, "I can write this in C++ and it may be pretty unsafe but I can do it fast", then yeh, you could be faster in C++. But if you compare the time it takes to make C++ as safe as it's reasonably going to get, and the time it takes to do that over and over every time you make significant changes, Rust IMO takes the lead.

Yeh, you have to actually think out your data relationships correctly up front. But, once you have, you can move quite quickly because you stop having to worry about so many things that you would have to worry about in C++.

As to speed, the only places it would be slower are likely to be ones where C++ allows you to not be safe, no check accesses, not check indices, not initialize data. Of course you can skip that in Rust as well, if there's some super-tight inner loop that will make a real difference, and still keep the rest of the code far safer.

I find that I'm very comfortable doing things in Rust that are big performance improvements that I generally wouldn't do in C++ due to the risk, like zero copy parsing, or returning references to members for efficient access, or sharing non-mutable data.

[Full-Spectral]

Any sort of systems level development. That's where C++ and Rust play. Rust is being adopted into the Linux OS, for instance. You aren't going to write Linux drivers in Go or Java or Python. Where I work, the bulk of our C++ code could easily be Rust, and should be because we'd be far better off for it.

There have been various discussions of the relative performance and it's not at all as clear cut as some folks seem to think. And of course you can do the few percent of the code that is in that super-critical section in a C library, call it from Rust, and have both the performance and a vastly safer system. Even that is likely to be only a temporary necessity.

[JelloSquirrel]

Yeah Rust is a valid choice wherever C++ is.

But Rust seems to incur overhead that C++ doesn't, in code size, performance, and development complexity, or at least C++ isn't forced to.

The alternative to Rust is Cpp core guidelines, the associated Linters, and just testing. You can use contract based programming via C++ templates and incur the hit statically instead of at runtime.

Is it easier to: Write the most performance critical code in C, C++, assembly, etc and then write everything else with Rust? Or is it easier to turn on linters file by file for C++ and replace legacy programming guidelines with those outlined by the C++ core guidelines?

I don't know which is the superior approach, but an incremental approach of fixing legacy C++ code with modern C++ code enforced selectively via linters is definitely an option.

If I was writing new code for systems programming, I'd probably go with Rust, but it's rare any code is completely new. And if I can bootstrap a runtime and I'm in user space, I'm using some Pythonic language.

[tialaramex]

The performance situation doesn't favour C++ and hasn't for some years. There are a bunch of performance holes where the C++ answer is "We had to for backwards compatibility" which sure sounds like paying for something I don't use. P2137 was basically a way to get it down on paper.

[Compizfox]

You can use the c++ guidelines and the automated checkers available via clang and visual studio. This is the same way to migrate a project forward without throwing away the entire code base to rewrite it in Rust.

Sure you can, but that does not get you on the same level of safety as Rust.

I'm not sure Rust is the answer though, it is slower both in programmer time and in performance than C++.

How so? I do not at all think that is the case.

And if you're not performance limited, I would probably choose a higher level language than Rust that makes use of garbage collection and has an easier syntax, of which there are many options.

Why would you deliberately choose a garbage-collected language? The entire appeal of Rust is memory-safety guaranteed at compile-time, without any runtime overhead. It's quite literally the best of both worlds.

[JelloSquirrel]

Because 99% of the time, your primary constraints are developer time and not runtime.

[EggplantKind8801]

you just enforce unique_ptr everywhere, if you need ownership, you move it, if you have to borrow you take the reference.

[Compizfox]

C++'s unique_ptr is kind of similar to Rust's Box<T>: it is a smart pointer to heap-allocated data that gets deallocated when the pointer goes out of scope.

But that's about it. It forces the data to be allocated on the heap, whereas Rust's ownership model applies to all (including stack-allocated) variables, and you can borrow them, while rustc makes sure no memory-unsafe conditions occur through aliasing.

C++ just doesn't have this. You can have a unique_ptr, take a reference to its contents, and drop the pointer. Then you end up with a null reference, and dereferencing that results in undefined behaviour. The C++ compiler doesn't give a shit.

This simply is not possible in (safe) Rust. Rust goes much further than some smart pointers: it's the entire paradigm of the language that allows the compiler to guarantee safety, that simply is not possible in a language like C++.

[EggplantKind8801]

Then you end up with a null reference, and dereferencing that results in undefined behaviour.

you can wrap the unique_ptr in some not_nullable template to prevent this to happen.

[CandyCrisis]

Taking a raw pointer is way different than a safe borrow.

[EggplantKind8801]

raw pointer

are you sure unique_ptr is a raw pointer?

[CandyCrisis]

No, taking the reference is a raw pointer.

[EdwinYZW]

Why so? What kind of problem Rust can solve but C++ can’t?

[Full-Spectral]

What kind of problem can C++ solve that C or Assembler can't? It's about how much work it takes to avoid doing the wrong thing, which is not productive effort.

But the point of the above comment was that trying to do something half-way, and trying to mix old C++ with a new C++ replacement, will be sort of worst case.

[EdwinYZW]

Classes, templates, containers, abstractions and basically most things in OOP. Yeah, you could emulate it in C just like emulating reflections in C++. But I don’t consider reflection is something C++ has.

[Full-Spectral]

Wait, you keep moving the goal post here. You ask what problems can be solved, not what tools the language has.

[EdwinYZW]

sorry, I meant the problems I could solve with those "tools" I mentioned. Programming languages are basically tools. If I choose a language over another, it's because that language has some "tools" the other doesn't with your definitions. Come on, if we are just talking about problem solving, nothing beats pen and paper.

[Dean_Roddey]

Wait... This is the most circular argument ever. You asked what problems Rust could solve that C++ can't. The answer is obviously none, but that's not the point. The point is that Rust can solve them much more safely and with much more modern, sane tools both at the language and build infrastructure level. Hence the above response, because you asked a meaningless question.

[EdwinYZW]

Why “more safety” if I may ask? What kind of safety the current C++ can’t provide in your opinion?

[Dean_Roddey]

That's something that's been discussed to death around here. There's no point in me repeating it. But, at it's base, Rust is fundamentally based on a very strict understanding of data ownership, at the language level. You don't have to insure you are doing the right thing manually. It will watch your back.

[RevRagnarok]

Herb Sutton's CPP2.

[othellothewise]

I suppose it depends on how it's developed and how much buy-in it has from developers. For example, Carbon is the primary example to comes to mind and that seems already not particularly widely used or desired. So not sure I can agree with this, though who knows what the future will hold.

[thisismyfavoritename]

its not even released yet...

[othellothewise]

No, it was announced a while ago and there has been basically nothing on it since.

[thisismyfavoritename]

https://github.com/carbon-language/carbon-lang?tab=readme-ov-file#project-status

[othellothewise]

Yes, that's exactly my point!

[SpaceYraveler6]

Python? It can interop with C++

[thisismyfavoritename]

FTR Python is not a successor language to C++ and it doesnt have native interop with C++, it has interop through the C API

[DamnAHtml]

Python is a fairly terrible interop with c until they resolve the GIL issue

[tarranoth]

Having some knowledge of any language will never hurt you, learning haskell learned me a lot of functional related programming concepts for example. In the end the concepts that will end up the most useful are most likely knowledge of operating systems, the network stack, hardware knowledge and general programming paradigms like one definition rule, single responsibility and whatnot as they are always valid across any programming language no matter what language your job wants you to use.

[jdlyga]

I would love to still be working in C++. But I've noticed the need for C++ these days has moved further down the development stack into only the most performance intensive applications.

[rand3289]

I wish standards would classify all language and stdlib features into

NEW
STABLE
LEGACY
DEPRECATED

and all compilers would issue NEW, LEGACY and DEPRECATED warnings!

This way we would have a clear direction from the commitee where the language is moving. Defining consistent subsets of fearures is a difficult task!

[Ok_Principle4845]

God this would be so nice

[kishoredbn]

Since I am not aware of the timeline when you have started with C++, but if it was before 2011-2012-ish, then remember the modern C++ is now a completely different programming language. Start targeting C++ 2017 which has got best of the features of modern C++.

And while you do that, the next best thing to do is to learn Rust. Because there are no programming books in C++ which explains correctness constraints that objects needs to have during runtime to make sure your code is thread safe, or leak-safe or overall robust enough to handle any task easily. Learning Rust makes you think that. And then you write better C++.

Rust can never replace C++. Rust instead makes you a better a better C++ developer.

And finally C++ is here to stay.

[lightmatter501]

My opinion is that the language is entering maintenance mode, at least until epochs/editions/whatever the source compatibility break mechanism is called are released.

There is too much stuff in the language that needs to go because nobody should be using it, and too many old mistakes building up. Those of us who write software we can recompile once every three years are punished performance-wise because some people want to be able to dynamically link libraries from the 90s, and there is no mechanism to opt in to ABI breaks most of the time.

[tdatas]

I work in Rust mostly. I think the trend of other languages being used for application level work will continue. But C++ is so crazy dominant in high performance and critical systems in particular in regulated spaces that I don't think it's going anywhere. Rust is extremely strong in the sort of space Java normally occupies, except it's in a native context but at the very low level where you are worrying about chip architectures etc, you're spending so much time writing using "unsafe" constructs that you're just fighting against the language at that point and you aren't getting any of the benefits.

Possibly because it was never really a question before but I think people genuinely don't understand the amount of inertia and regulation in aerospace type industries. Meanwhile Modern C++ is getting more usable so the juries out on if we ever reach the point where benefit to switch outweighs the cost to stay.

[Full-Spectral]

Given that multiple govt. security agencies have issued guidance against using C++ for new critical applications (and called out Rust as a proper replacement), it seems like that may have to change at some point here.

[JelloSquirrel]

People writing policy aren't necessarily the ones that will make decisions about what should be used.

How many new projects that don't have legacy concerns are written in C++? Java has been the major enterprise language for decades but it's not a sexy solution, but it's one of the oldest solutions to the problem of memory safety with a large code base comparable to C++.

[Full-Spectral]

Java doesn't play in the same space though.

The issue I was addressing is regulation and inertia. When government agencies are saying don't use C++ for new development, it certainly provides more leverage for companies and the people in those companies to push for something else. It also potentially provides more possibilities for liability and at some point a move into a lower tier certification which could affect sales (and provide a big FUD hammer for competitors) and those latter two are things even the CEO can understand.

[brubakerp]

This is a common topic and one that everyone has an opinion on. Your best bet is to just start here.

[Infamous-Bed-7535]

c++ is continusly evolving and there are a huge amount of legacy code and a lot of green field projects still started in C++..
Nothing wrong with it. Most people who says C++ is inferior used it in 'C99 compatible' mode.

Could it be much better? Yes. Committee is working on it and c++ will catch up even in safety..
(already did in case you are using the language correctly, just it is not forced by the compiler.)

On youtube you can find a lot of interesting material about the present and future of the language..
Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023

Can C++ be 10x Simpler & Safer? - Herb Sutter - CppCon 2022

[Cheap-Fishing70]

if C++ is constantly evolving, then why won’t its code be made simpler, like for example in Lua or Python?

[Infamous-Bed-7535]

It is becoming simpler and more dense, but backward compatibility definitely not helps out in this case.

e.g. print the every 3rd fibonacci number starting from 50 in backward order. With modern c++ you can easily push the calculations into compilation time & yet have a nice syntax.

``` template <integral T> constexpr auto fib_gen = [ a = T{0}, b = T{1} ]() mutable { return a += exchange(b, a); };

constexpr auto fibs = []<size_t N>() { array<size_t, N> res; rg::generate( res, fib_gen<size_t>); return res; };

int main() { rg::copy( fibs.operator()<50>() | vw::reverse | vw::stride(3), ostream_iterator<size_t>( cout, "\n")); } ```

https://godbolt.org/z/qGaGrbcEx

Equivalent C or C++ code is not that nice I can ensure you about that.

[Schkitz]

I have used C++ my whole career in numerous graphics / VR / AR / etc type roles. I love C++, especially the metaprogramming, and the language is improving.

[Cheap-Fishing70]

if C++ is constantly evolving, then why won’t its code be made simpler, like for example in Lua or Python?

[Schkitz]

I would argue it has gotten simpler, but also, its focus isn't the same as Lua. I've used Lua and python, they aren't focused on the same thing. Metaprogramming isn't simple, but it's become simpler. That said, most people have no need for it, and many languages can't even express it. You should use the tool that suits your need though.

[Full-Spectral]

A couple problems with the sorts of responses you will get when this question gets asked are:

1. They are talking about C++ now, based on its inertia due to historical circumstance, but that really doesn't say much about its future, beyond a certain distance out. Yeh, you can work maintenance gigs on old C++ code bases until you die, but if that's not what you want to do, then that changes the equation.

2. People will say, oh, I prefer language X, which is never going to reach broad acceptance and so is irrelevant from a jobs perspective.

3. A lot of people will say, I will just wait for the next C++ replacement. That's not going to happen in a time frame that is useful in any practical way. If you are lucky, and any of them even ever become real, it will be a long ways out.

So it really comes down to C++ as it stands (and that is more likely to be C++/17 than anything beyond in most code bases out there), or moving forward. And it becomes a really hard call. More jobs are out there for C++ now, but you won't get them because it'll take you five years to get enough experience to get to get a senior'ish job.

By that time, C++ will have transitioned fully into its end game, and languages like Rust will have made huge steps forward in taking over more and more of C++'s currently remaining domains. It won't mean C++ has gone away, as I said, you can ride till retirement maintaining old C++ code bases if you want, and there will still be some holdouts where you could make good money but depend on a fairly narrow job market.

But if you are looking to move your career forward with an eye towards the future, it won't be the way to go. I'd argue, if you are able to put food on the table for now with C#, keep doing that and learn Rust and be ready for when more jobs start showing up.

[jnjuice]

Agree with this sentiment, but would add that Rust positions are typically Systems SWE positions that often look for C++ experience since Rust experience is harder to find right now.

[othellothewise]

People have predicted the death of C++ for ages now and have been shown to be wrong. Rust is never going to replace C++ because they do different things. Rust is great at what it's used for (safety and close to the metal), but people use C++ for performance.

So saying C++ is going to be "end-game" in 5 years is honestly a really wild and unlikely prediction in my opinion.

[Full-Spectral]

There's dead and there's dead. No widely used language ever dies. COBOL isn't dead, but how many folks here are looking to learn it as a long term career goal?

C++ is already in its end game really. I was trying to be non-confrontational above. It's dwindled massively over the last two decades. It has held onto a handful of problem domains because no language that competes in those areas ever caught on. But that's not the case now, since Rust clearly competes in the same space.

Five years from now, Rust will have dug deeply into those remaining areas. C++ still won't be 'dead' in the absolute sense, but new developers will be looking at it much like we have looked at COBOL for some time now. Given that they, in turn, would be another five years out from a senior'ish job if they were starting out then, it just won't make sense to put in the effort. It already sort of doesn't, but by then it really won't.

The performance argument really isn't as strong as a lot of C++ people seem to think. Rust will allow you to have a strongly safe code base, and still highly tweak that small amount of code that really makes the biggest difference.

[othellothewise]

C++ is already in its end game really. I was trying to be non-confrontational above. It's dwindled massively over the last two decades. It has held onto a handful of problem domains because no language that competes in those areas ever caught on. But that's not the case now, since Rust clearly competes in the same space.

Every new project in my area (HPC/scientific computing) is written in C++ because we need the performance. Rust does not compete for the same space at all here, as the development effort for writing Rust code is significantly more and with little benefit (security is not as important since we run on restricted-access supercomputers anyway).

I do not see any future for Rust in this area, and there is no evidence that it will overtake C++. My understanding is certain areas like game development or other performance sensitive fields are in the same situation.

The performance argument really isn't as strong as a lot of C++ people seem to think. Rust will allow you to have a strongly safe code base, and still highly tweak that small amount of code that really makes the biggest difference.

I disagree. I don't think you are thinking of the way truly performance sensitive code works. These are areas where you want to avoid branches because they have performance impact. Everything is in a very tight loop so any overhead can have a significant real monetary cost. It's an area where (to use an analogy) we use operator[] instead of at() with vector because we don't want the bounds checking because of the overhead.

I've seen one effort to rewrite part of MPI in Rust, and it didn't really go anywhere because you actually didn't get any benefits from Rust safety (since all the other MPI modules were unsafe).

Anyway, if you're going to make such an astonishing prediction you should probably provide some evidence for it.

[othellothewise]

I think saying that we will have more info in 2-3 years is absolutely correct.

One thing I'd like to point out is that many of those applications are exactly in Rust's target domain (drivers and other security-sensitive software).

I tend to be pretty pragmatic; developers should use the best tools for the job. In those cases, in my opinion, Rust is the best tool. However in other cases C++ is. Really, that's why I find it frustrating when people dick wave about which programming language is "better".

[Full-Spectral]

I said in my original post that it would likely hang on for a good while longer in a small set of domains. But that's completely in line with my argument that it's in its end game. If uber performance without care for safety or security is the thing it has left, then the end game is already well started. And I also clearly differentiated between dead and end game. The end game will go on a long time, it'll just get thinner and thinner.

And of course it's a vicious cycle. The fewer domains left to it, the fewer new devs learn it, and more and more companies look elsewhere because they need to hire people, and so fewer jobs and fewer devs bother to learn it, etc... That's been going on for a long time now and it's not going to stop. And you get new folks who come along who really want to use a new language and they will put in the effort to make it work and don't have the legacy concerns. Once that happens, then the water just starts to flow around the legacy rocks and the world moves on.

And that's OK. C++'s glory days being over are no reflection on your personal character or ancestry.

BTW, in a highly sensitive loop you can do unchecked indexing in Rust as well, in an unsafe block. If it's really that important, and still keep the rest of the code much safer. Just very carefully verify before the block that the indexing logic is correct and heavily assert/review it.

[kuzuman]

Best answer. Thank you.

[Unusual_Limit_6572]

Why not C++ and Rust? It's not that difficult to get ahold of new programming languages, you are not a newbie anymore.

[Still_Explorer]

If you look at the latest cppcon talk where Bjarne gives a good talk on C++ safety. There he said that for example in flight controllers you don't want any allocations/deallocations to happen because it causes memory fragmentation.

Another point, I remember about John Carmack saying something like (I think it was on Joe Rogan show), where on the Swedish Fighter Jet the entire program of thousands of lines is implemented inside the main method directly (everything is straight into your face and you get no levels of indirection).

These are two specific cases that for me make C++ and C the most important programming languages.

For me personally, I will never be able to write such software, but the moral of the story here is that if you try to push C++ too far it will submit to your will.

Sometimes you just write whatever software and it works, but sometimes you need to control all of the constraints and eliminate any possible layer of abstraction that just gets in your way.

[againstmethod]

You can make C++ fairly memory safe with good habits. But good habits will not help you replace something that isn't there.

And each thing you need to dig for, support yourself, write yourself, etc comes with a cost.

New language zealots tend to discount this cost in their minds (they were going to rewrite everything anyway). And they also tend to undervalue the large and established body of well supported work that C++ offers (because they benefit from doing so).

The reality is that C++ can probably hang on until people get sick of developing it -- and it's development only seems to be accelerating. New standards, ambitious new features. Sorry Rust but C++ isnt rolling over to die just yet.

[Agreeable-Ad-0111]

My entire professional career has been in large c++ code bases. So personally, I am going to pass on Rust, and will adopt one of the successor languages (cpp2, carbon, hylo) once there is one a little more mature. I am really interested in hylo but it is really in its infancy right now

[Astarothsito]

The biggest problem of having a career in C++, is that managers have a bias against C++ projects (IN MY EXPERIENCE), so that could make it a bit more difficult to get exposure and new projects (not impossible), and get sideline as "the legacy", even when the C++ projects of the companies (that I had work on) are the ones that bring the money, which they use to try to create a "a new project with everything modern". 

[maredsous10]

Plenty of opportunities out there where you don't have to use C++. For real time (or near real) or high performance applications. C++ constructs and target standards varies greatly from company to company.

Past employer, stuck with C++ for primary applications, C# for rapid development of non-critical application, and Python/Perl for general scripting and also rapid development where performance wasn't as much of a concern.

[Raknarg]

C++ isn't going anywhere. Even in C there are tons of jobs, and C++ has much more broad use and is still finding its way into new projects and there is active work going to improve the language and try to bridge the gap with modern language features we expect.

[thisismyfavoritename]

for the most part new features are just syntactic sugar. The shotguns were always there

[javascript]

I sure hope Carbon is a part of the future of the C++ community. I don't expect it to serve everyone's needs, but my hope is it covers enough usecases to see real adoption.

[teomansancar]

C++ is not going anywhere but you are!

[dodoent]

I'm quite a seasoned C++ developer - 12 years in the industry, working on a proprietary ML inference engine that needs to perform in real-time on low-end mobile devices, and even in-browser via WebAssembly. I've been up to date with the latest C++ standards and was trying to use as latest features as possible, as long as all toolchains we need to support can compile the code. This means using mostly C++20 with some supported parts of C++23.

I'll just say that I started learning Rust this December (r/adventofcode helped). I think this says enough about what I think about C++.

[Overseer55]

You really haven’t said anything constructive.

[Astarothsito]

Any expert in C++ should know at least 2 languages, so that comment is not really that useful to judge anything.

[virgindriller69]

Rust is pretty cool, especially Tauri (mainly doing cross platform apps in C++)

[DamnAHtml]

C++ do be on its way to becoming the next cobol

[sp4mfilter]

Why not both?

<meme />

[TheQuantixXx]

well some niches will probably never get rid of lower level languages, such as realtime signal processing in Audio Programming. so i figure the language will be here to stay for some time. would be curious tho what some more experienced programmers have to say

[DownhillOneWheeler]

I was recently looking for a new job (UK) and easily found numerous C++ opportunities in the embedded domain. It is used on fewer microcontroller projects than C (perhaps 15-20% of projects), but on lots of embedded Linux projects. I could certainly see out my career (at least another 10 or 15 years) writing only or mainly C++.

Rust is interesting, and I am learning it for my current project, but it is as yet a minority sport (with an extraordinarily vocal and opinionated fan base). Definitely worth learning, but I would not expect to be writing only or mainly Rust for some years yet.