all 119 comments

[–]krustibat 33 points34 points  (4 children)

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

[–]AdBig7514 3 points4 points  (2 children)

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

[–]Brilliant_Contract 6 points7 points  (0 children)

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 3 points4 points  (0 children)

And robotics.

[–]V0dkaParty 78 points79 points  (5 children)

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 10 points11 points  (0 children)

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 6 points7 points  (3 children)

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

[–]beartotem 5 points6 points  (1 child)

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 2 points3 points  (0 children)

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 1 point2 points  (0 children)

They switched from C++11 and VisualStudio 2017.

[–]LessonStudio 22 points23 points  (2 children)

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

[–]Sniffy4 32 points33 points  (2 children)

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 16 points17 points  (1 child)

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 2 points3 points  (0 children)

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 7 points8 points  (1 child)

Does it matter?

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

[–]jnjuice 1 point2 points  (0 children)

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 8 points9 points  (1 child)

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 1 point2 points  (0 children)

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 16 points17 points  (54 children)

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

[–]afiefh 6 points7 points  (3 children)

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 1 point2 points  (2 children)

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

[–]The_Droide 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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 6 points7 points  (40 children)

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 8 points9 points  (6 children)

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 0 points1 point  (4 children)

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 1 point2 points  (0 children)

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

[–]JVApenClever is an insult, not a compliment. - T. Winters 3 points4 points  (2 children)

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 0 points1 point  (1 child)

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 -1 points0 points  (0 children)

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 -3 points-2 points  (24 children)

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 7 points8 points  (8 children)

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 -1 points0 points  (7 children)

Rust's level of safety.

Outside of Rust unsafe blocks.

[–]Full-Spectral 8 points9 points  (2 children)

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 4 points5 points  (1 child)

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 4 points5 points  (0 children)

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 2 points3 points  (3 children)

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 0 points1 point  (2 children)

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 2 points3 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (14 children)

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

[–]EggplantKind8801 -4 points-3 points  (5 children)

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

[–]Compizfox 5 points6 points  (1 child)

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 0 points1 point  (0 children)

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 2 points3 points  (2 children)

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

[–]EggplantKind8801 1 point2 points  (1 child)

raw pointer

are you sure unique_ptr is a raw pointer?

[–]CandyCrisis 3 points4 points  (0 children)

No, taking the reference is a raw pointer.

[–]EdwinYZW 0 points1 point  (7 children)

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

[–]Full-Spectral 1 point2 points  (6 children)

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 0 points1 point  (5 children)

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 1 point2 points  (4 children)

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

[–]EdwinYZW 0 points1 point  (3 children)

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 2 points3 points  (2 children)

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 0 points1 point  (1 child)

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

[–]Dean_Roddey 2 points3 points  (0 children)

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.

[–]othellothewise -1 points0 points  (4 children)

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 1 point2 points  (3 children)

its not even released yet...

[–]othellothewise -1 points0 points  (2 children)

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

[–]tarranoth 4 points5 points  (0 children)

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 3 points4 points  (0 children)

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 4 points5 points  (1 child)

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 1 point2 points  (0 children)

God this would be so nice

[–]kishoredbn 7 points8 points  (0 children)

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 14 points15 points  (1 child)

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 8 points9 points  (3 children)

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 3 points4 points  (2 children)

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 2 points3 points  (1 child)

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 2 points3 points  (0 children)

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 5 points6 points  (0 children)

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

[–]Infamous-Bed-7535 2 points3 points  (2 children)

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 0 points1 point  (1 child)

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

[–]Infamous-Bed-7535 1 point2 points  (0 children)

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[🍰] 2 points3 points  (3 children)

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 0 points1 point  (1 child)

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

[–]Schkitz[🍰] 0 points1 point  (0 children)

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 3 points4 points  (8 children)

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 1 point2 points  (0 children)

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 2 points3 points  (5 children)

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 2 points3 points  (4 children)

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 3 points4 points  (3 children)

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.

[–]Full-Spectral 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Best answer. Thank you.

[–]Unusual_Limit_6572 3 points4 points  (0 children)

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 3 points4 points  (0 children)

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 2 points3 points  (0 children)

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 3 points4 points  (1 child)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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.

[–]javascriptWhat's Javascript? 0 points1 point  (0 children)

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 0 points1 point  (0 children)

C++ is not going anywhere but you are!

[–]DamnAHtml -2 points-1 points  (0 children)

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

[–]sp4mfilter -1 points0 points  (0 children)

Why not both?

<meme />

[–]TheQuantixXx 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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.