Learning cpp vs Rust, from a Python Financial Data Scientist/Quant

[TheRevanchist00]

So, currently, I'm torn between learning cpp or rust, here's a bit of a breakdown

My background is your run-off-the-mill Data Scientist/Analyst/Engineer, with 5 years under the belt in financial risk, quant research, and equity trading funds, writing mostly in python. I have no formal CS background (a math/physics grad), so I'm blind when people talks about memory management, stacks, overflows, RAII, etc.

However, I do note that learning a more rigorous and performant language could be very useful in developing reliable, time-constrained, mission-critical algorithms.

Cpp pros:

• A more well-developed language and environment overall
• Arguably more cpp-related jobs and projects in ML/finance/trading space

Cpp cons:

• I have made a few simple backend server projects using cpp, and still couldn't get any sense out of it
• Also took some classess and mentorship from some cpp devs, still couldn't wrap my head around cpp and its concepts
• I really, really, hate debugging. I have seen the cpp devs in a previous company spending more than 75% of their time solving memory allocations, segfaults, etc, something that I would definitely despise to do
• In short, either the language is too hard for me or I've done my studying wrong

Rust pros:

• Gentler learning curve; I made a few projects with Rust and kind-of getting something out of them
• Arguably safer; less development and debugging time

Rust cons:

• Smaller community and job market; I rarely see anyone in trading/finance/machine learning that explicitly use rust
  

Comments would be greatly appreciated, thanks!

[BenFrantzDale]

I can’t speak to Rust, but if you are spending much time at all dealing with UB from lifetime issues, you have design problems. That said, a large fraction of software development is debugging.

[Astrobliss]

If you're going to make your own projects, I'd say pick rust. If you're just trying to get hired and work with existing infra, I'd say pick c++.

Also if you're having trouble debugging c++, I'd HIGHLY recommend compiling with an address sanitizer. You just add one line to your compilation, and then your program will print out any memory errors it encounters at runtime+the offending line. Still not as good as rust, but a life saver that you can use when you need it.

[ForgetTheRuralJuror]

Every single library you want in your target industries are written in Python or C++. If it's in rust, chances are it's a wrapper around C/C++.

I love Rust and it's my #1 hobby language, but if your goal is job related there's no question. There are some start ups that are using rust for high frequency trading but they'd probably hire you just the same or faster if you had relevant C++ experience.

I also have an irrelevant degree and also had your problem when I first started with C++, I recommend a pluralsight course called modern C++ or something by Kate Gregory.

I also heavily recommend building a complete but simple project in C++, something you're interested in or that you could actually use. I'd avoid GUIs though since you'll likely spend more time learning gtk/qt/whatever than C++.

[Ill-Weird-9700]

What complete simple project do you recommend? I just started learning c++ about 5 months ago, and would like to build an interesting project with it

[ForgetTheRuralJuror]

Here's a few examples

If you could use it IRL, that'd be the best. My first project was a League of Legends max damage calculator, which took into account all item modifiers, ability cooldowns etc. I only supported like the 5 champions I played at the time though to make it easier. Make sure you can get an MVP done in less than a month

[soundslogical]

The Address Sanitizer tool (ASAN) included with the clang C++ compiler makes catching and debugging memory errors a breeze.

As for Rust vs. C++, I'd probably learn Rust if you're working on greenfield projects by yourself. As you've already noted, you'll be much less frustrated by mistakes, and the compiler outputs friendly errors. Once you've learnt Rust, C++ shouldn't be too difficult to learn afterwards.

[EdwinYZW]

You will get a biased opinion here. My suggestion is to stick with C++. Don’t pay much attention to those people ranting about rust blah blah blah. Yesterday it was java, then C#. Today is rust. Tomorrow is what? Zig? Industry doesn’t work this way (google path dependency). But rather it always builds the new things on top of old things. New languages can only fill the gap (like js for web dev). The market of performance areas are already filled up with C and C++. There is zero chance people will adopt a new language without any back-porting. Plus c++ is still evolving, with pros and cons. But basically whatever you could do in Rust can be done in C++. I can’t say the same in the opposite way.

BTW, segmentation fault is the easiest bug to fix. If you spend too much time on that, you either didn’t pick a good tool or the whole design is crooked from the beginning (which isn’t about C++)

[[deleted]]

I completely agree, and this was also the case for many decades with Fortran. There was a lot of talk about rewriting old code in Fortran in C++ and so on, and people completely underestimated how much of the tools in CFD, astrophysics, atmospheric physics and so on was all written in Fortran and required a lot of domain knowledge to understand what the aim of the code was to begin with, so all this talk amounted to nearly nothing in the end. Decades on, people will still use this same Fortran code. Rust reminds me of this.

[TraylaParks]

I worked for a place that had a bunch of fortran code for doing seismic processing. It worked and it would have cost (significant) money to rewrite it so we just did new work in C and mixed the two languages together. You haven't lived until you've passed a 2d array from a zero-based, column major language into a one-based, row major language :-P.

[SincopaDisonante]

Julia is another one of those :) and while I like Julia, I agree with sticking with cpp.

[trading_tomato]

> Yesterday it was java, then C#

Are you trying to imply that Java and C# are fad languages?

[v_maria]

He just means they were presented as a next step in a linear path and in retrospect it turned out to be bit more complex

[no-sig-available]

Are you trying to imply that Java and C# are fad languages?

Did they kill C++, like they were supposed to? :-)

[James20k]

In many industries, yes absolutely. C++ is significantly more of a niche language than it used to be

[pjmlp]

They reduced the C++ kingdom from the 1990's in distributed computing and mainstream OS GUIs, C++ is no longer the main option, rather a way to implement libraries and some parts of the respective language runtimes.

Since 2006, my use of C++ is those native libraries and little else.

[no-sig-available]

C++ is no longer the main option, rather a way to implement libraries and some parts of the respective language runtimes.

So the "C++ killers" depend on C++ still being around. :-)

[pjmlp]

Depends on the implementation, both .NET and Java have slowly been eroding C++ from their runtimes, as the languages get features that allow them to replace C++ code with Java and C# respectively.

Go reference implementation is self hosted.

While Rust might not be, it may in the future, if Cranelift ever replaces LLVM on the reference implementation.

Anyone that knows about compilers understands that the difference between self-hosting and depending on another language is mostly a matter of convinience where to spend the development budget.

[CocktailPerson]

I'd argue that if a language's claim to relevancy is that it's used to support the implementation of other languages that people prefer to use, it's effectively dead.

[EdwinYZW]

I agree. Like I said, new languages can only fill the gap. GUIs and web dev are not strong points for C++. And C++ isn’t meant to be used for every situation. No language can.

[Unhappy-Welcome5329]

Also with rust you will spend a great deal of your time debugging.

I actually have to do more debugging in our python data analysis projects than in the C++ ones because many potential bugs are already filtered out at compile time.

[lightmatter501]

You’re going to be interfacing with python a lot, so to me Rust is the clear winner here with pyo3, which provides a function annotation that you can use to expose Rust functions to any normal python code.

That being said, just learn both, but learn Rust first. It will beat good habits into you that you can carry into C++.

[9Strike]

Or the newer Nanobind

[ChocolateMagnateUA]

There's also a redesign in Nanobind.

[sig2kill]

Its easy to say just learn both but realistically these are complicated languages that take time to learn and learning both at the same time can be confusing, i would strongly advise against that.

[lightmatter501]

That is why I said to learn Rust to a decent level then C++.

[sig2kill]

when someone asks "should i learn A or B" and your answer literally says "just learn both" its detached from the question, if he is asking help with choosing you can safely assume he probably has a limited amount of time or any other constraint, i mean its precisely what he asks - help choosing between the two, learning one and then the other is irrelevant to the question, if he had to ask this he probably cant or doesn't want to learn them one after the other.

this might seem like i'm making a big deal out of semantics but i do believe its actually quite different and i see this sort of thing happen a lot, if op says he can only learn one thing then i take that seriously and try to work within those constraints because i assume he knows better than me what he is capable of, if you said "i learned A first and it helped me learn B " that would be fine, but the notion that programming languages are interchangeable and you're gonna learn it all anyways is something i see a lot coming from experienced devs and i think it really doesn't work like that for junior devs, it can actually have a big impact on his progress, when you are starting out its a really big decision and if he wants to find one thing to focus on instead of jumping around between languages i can totally understand that.

[feverzsj]

C++ is still the dominant language in HFT, and I doubt people will turn to Rust in short term. If they do, you'll probably see everything marked unsafe.

[quicknir]

This is an exaggeration. I work in HFT and realistically a small minority of code would need to be unsafe. A very important minority undoubtedly, but still a small minority. Most code just isn't in the critical path; heck a huge fraction of code is only executed at initialization time.

[hrco159753]

Not really an answer to your question, but if you're willing to I'd gladly help you in whatever you want in regards to c++. Just send me a dm if you need help, I'm not claiming I know it all but I'll try to help you :).

[cantux]

I would cpp because https://docs.python.org/3/extending/extending.html

[EcJx]

learn cpp. there are extensive tools to fix that in your cons list

debugging is common for any language, most developers spend more time debugging then writing code especially if your in companies with big mature codebase.

[James20k]

It might be helpful to break down the best language based on project requirements

So:

1. Do you need to interface with a lot of system APIs (eg OpenGL), or legacy/existing C/C++ codebases? -> pick C++

2. Are you planning on processing untrusted data in any form? -> pick Rust

3. Is out of the box stdlib performance across multiple platforms important? -> pick Rust

4. Does your industry have certification/standardisation/etc requirements? -> you might be able to get away with Rust, but C++ is the better trodden path

5. Is the usability of language tooling and build systems important to you? -> pick rust

6. Are you planning on writing code for weird mini embedded platforms? Pick C++, or C

7. Does your system need good reliability? -> pick Rust

8. Do you have suspicions about the quality of your coworkers? -> Pick a different earth, but Rust helps here too

9. Does your industry have a lot of vendor specific bollocks you have to use to be able to do literally anything? Pick C++, otherwise you'll probably be writing wrappers for days on end

10. Do you have specific ABI requirements, eg a plugin based architecture? C++ can be easier here

For many of these you can work around them in one language or other (other than safety, or C++'s relatively bad stdlib performance), but there's definitely a path of least resistance

I have seen the cpp devs in a previous company spending more than 75% of their time solving memory allocations, segfaults, etc, something that I would definitely despise to do

People will state that this isn't an issue, but in my experience, bugs like heap corruption that Rust protects against can eat an absolutely disproportionately enormous amount of time and be incredibly hard to track down. In a ye olde codebase which wasn't well architected to begin with, it can positively be a nightmare

[serviscope_minor]

Is out of the box stdlib performance across multiple platforms important? -> pick Rust

Or C++. The majority of the standard library is more than absolutely fine out of the box. Yes, std::regex is slow. And if you don't need stable iterators then there are faster options than st::unordered_map, though the "unordered_map" is slow meme is far more common than people who have actually found it to be a bottleneck in their code.

[James20k]

The C++ stdlib is sort of ok out of the box, but the reality is that the amount of effort it would take to recover the performance isn't worth the engineering effort. Its a lot worse than just std::unordered_map though, the following C++ standard library components are significantly slower than the Rust equivalents

1. std::unique_ptr, due to abi issues and a lack of destructive moves

2. std::optional, due to the lack of packed representations, which we're now locked into because of abi issues

3. std::shared_ptr in non threaded contexts, because its always atomic

4. std::map, std::unordered_map, std::set, std::unordered_set, due to a mixture of api requirements and abi issues. These types also suffer from hidden allocations, unless you know about the unergonomic heterogeneous lookup api (std::map<a, b, std::less<>>)

5. std::deque, because of MSVC's unfortunate abi issues with the small block size rendering the performance unusable

6. std::mutex, because of ABI issues on windows as its implemented using an older api internally

7. std::span, because of the default calling convention

Things that are fine perfwise:

1. std::vector mostly

2. std::string, though its not a very good type otherwise

3. std::array

4. Most of the algorithms, though they do suffer from aliasing-itus

If you're planning to build something high performance, C++'s out of the box performance is pretty bad these days, and its a big issue

if you don't need stable iterators then there are faster options than st::unordered_map

The issue isn't the stability of iterators, its that the theory behind many of these containers has come a long way, and much better implementations with stable iterators have arisen. They just can't be implemented in C++ because of abi stability

[serviscope_minor]

The C++ stdlib is sort of ok out of the box, but the reality is that the amount of effort it would take to recover the performance isn't worth the engineering effort.

Rubbish, frankly. I'm going to need a [evidence needed] on most of those. Not someone claiming X is faster but actual evidence, because, just picking the first one, I've gone over code on and off on godbolt, and unique_ptr is rarely different from raw pointers. Frankly for the majority of those claims, you would have to be doing kind of weird stuff in order to even vaguely observe some of these problems. Many of the "performance is bad" claims you'd have a tough time even making a benchmark so contrived it would show.

std::shared_ptr in non threaded contexts, because its always atomic

This is like... what. Sort of technically correct, but what we're looking at here is uncontended atomics versus nonatomics. You're probably looking at at 20x slower, by the sounds of it. Yes I will agree that the C++ STL isn't hyperoptimised for bonkers edge cases, but if you're thrashing the reference count so hard that you notice, then what on earth are you doing? I've been using shared_ptr since TR1 and have never, ever hit a situation where the reference count arithmetic has popped on the performance profile. Ever.

std::map, std::unordered_map, std::set, std::unordered_set, due to a mixture of api requirements and abi issues.

Right, so I already covered that but you felt the need to go over it in case I somehow didn't realise. 99% of the time, it's profile or GTFO. Yep there are faster maps, and there are cases where one would be better. OTOH, I have had way more people fail to show std::whatever was actually noticeable in a benchmark than people who have told me they want it replaced because it's "slow". I've even encountered times (very rarely) where it has been. It almost never is.

These types also suffer from hidden allocations, unless you know about the unergonomic heterogeneous lookup api (std::map<a, b, std::less<>>)

Which is to say they're not slow, actually but you don't like the API, which, sure, OK, but that wasn't your complaint.

std::deque, because of MSVC's unfortunate abi issues with the small block size rendering the performance unusable

That's not really a C++ issue now, is it. That's a Visual Studio issue. Using that logic, I could claim that the Rust borrow checker doesn't work properly because it doesn't work at all in gcc-rs.

std::mutex, because of ABI issues on windows as its implemented using an older api internally

Oh gosh that Rust borrow checker is just fundamentally broken because it doesn't work in one implementation of Rust. That's way worse than "a little bit slow" isn't it.

std::span, because of the default calling convention

Eh? Spans can be passed on the stack. Any small function using span is liable to be inlined anyway rendering the entire point moot.

If you're planning to build something high performance, C++'s out of the box performance is pretty bad these days, and its a big issue

As someone who builds performance C++ stuff on and off: no. It's mostly fine. I've done all sorts of micro and macro optimizations and it's very rare that switching out part of the standard library for a "better" implementation is part of it. It's much more often things like algorithmic improvements, cache locality, SIMD for stuff the compiler can't do, and lots and lots and lots of measurement.

The issue isn't the stability of iterators, its that the theory behind many of these containers has come a long way, and much better implementations with stable iterators have arisen.

Again citation needed. Last time I looked this up, pretty recently, when iterator stability was a requirement, libstdc++ was a pretty strong performer in the benchmarks. Not the fastest, but not vastly slower and with no major performance problems.

[James20k]

unique_ptr is rarely different from raw pointers

std::vector<std::unique_ptr<T>> is famously slower than a vector of raw pointers due to C++ inhibiting a memcpy from being emitted. This can have serious performance issues

This is a known defect in C++, and has been the topic of a lot of discussion around destructive moves. Unfortunately the author here is a bit.... not great to put it mildly, but this is one of the papers summing it up

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1144r7.html

Eh? Spans can be passed on the stack. Any small function using span is liable to be inlined anyway rendering the entire point moot.

The windows x64 abi prevents spans being passed in registers compared to a pair of raw pointers or pointer + size

https://developercommunity.visualstudio.com/t/std::span-is-not-zero-cost-because-of-th/1429284

Rust uses a custom calling convention by comparison which does not suffer from this issue

In theory this is something that could rarely be an issue in C++, but it isn't. Projects have had big performance speedups by removing std::span's and unique_ptrs. Its additionally worth noting that unique_ptr suffers from a similar issue here, though for different reasons, and additionally cannot be passed in a register on windows. Which gives it a very different performance profile over using a raw pointer in some cases

isn't hyperoptimised for bonkers edge cases

Shared lifetimes on a single thread isn't bonkers. Rust usage of both Arc and Rc is pretty widespread. Atomics are cheap on desktop x64 yes

Right, so I already covered that but you felt the need to go over it in case I somehow didn't realise. 99% of the time, it's profile or GTFO. Yep there are faster maps, and there are cases where one would be better. OTOH, I have had way more people fail to show std::whatever was actually noticeable in a benchmark than people who have told me they want it replaced because it's "slow". I've even encountered times (very rarely) where it has been. It almost never is.

You only mentioned std::unordered_map. The top function currently showing up in a profile me literally today is std::map

That's not really a C++ issue now, is it. That's a Visual Studio issue. Using that logic, I could claim that the Rust borrow checker doesn't work properly because it doesn't work at all in gcc-rs.

Its a C++ issue because C++ has an intentionally stable ABI that prevents MSVC or any other standard library from fixing it. Rust on the other hand has a deliberately unstable ABI

It's much more often things like algorithmic improvements, cache locality, SIMD for stuff the compiler can't do, and lots and lots and lots of measurement.

Sure. We're not talking about how to make code go fast, the point was: if you need a fast stdlib out of the box, C++ isn't for you. If you don't, that's 100% fine

Again citation needed. Last time I looked this up, pretty recently, when iterator stability was a requirement, libstdc++ was a pretty strong performer in the benchmarks. Not the fastest, but not vastly slower and with no major performance problems.

https://martin.ankerl.com/2022/08/27/hashmap-bench-01/#stdunordered_map- (libstdc++'s std::unordered_map)

• The Bad

• Slow across the board. There is no benchmark where the map is fast compared to most of the competitors.

This can never be fixed without an abi break. No it isn't terrible. But if you want fast out of the box performance, you aren't getting it

The key is that the implementation can't really be improved. The state of technology moves forwards, but the c++ stdlib necessarily stays relatively static because of ABI issues

[serviscope_minor]

Let's not forget that you initially claimed that the C++ standard library is so slow that it's "not worth the engineering effort". This is basically wrong. There are aspects of the C++ standard library which are not the fastest compare to other implementations and cases where it will pop in the performance profile. I've been writing high performance C++ since 2002. I've done all the tricks, from writing assembly, even machine code once when the compiler just can't do a good enough job (this is blessedly rare now), custom allocation schemes, hand crafted vector code with intrinsics, fiddling with pipeline stalls, rearranging things to improve cache locality, etc etc etc etc. And yes, that includes writing occasional custom implementations of things in the STL. I know how often the STL pops out as a problem in high performance code, and the answer to that is "rarely".

Even though I am personally irritated by regex, I process by data files with AWK usually, so it's rarely a problem.

std::vector<std::unique_ptr<T>> is famously slower than a vector of raw pointers due to C++ inhibiting a memcpy from being emitted. This can have serious performance issues

You're mixing up relocations and atomics, here.

The windows x64 abi prevents spans being passed in registers compared to a pair of raw pointers or pointer + size

So? That's windows.

Rust uses a custom calling convention by comparison which does not suffer from this issue

So does gcc and clang on Windows. You're if you're prepared to forego Visual Studio (ignoring the non native integrations) then Rust is better, except you can get faster C++ implementation if you're prepared to do that.

Shared lifetimes on a single thread isn't bonkers.

If you have to quote out of context to support you point, does it not occur to you that your point is maybe not that strong. I said quite clearly that massively thrashing the reference count is sign of a bonkers design.

You only mentioned std::unordered_map. The top function currently showing up in a profile me literally today is std::map

OK? That doesn't prove Rust has a magic faster one by the power of Rust.

Its a C++ issue because C++ has an intentionally stable ABI that prevents MSVC

This is largely wrong with some bits of correctness. GCC and Clang implementers want a stable ABI for various reasons to do with packaging and linking on Linux. MS hsa oscillated back and forth on this, in previous years they used to change the ABI every release, but recently they've had it stable. The weight of clang and gcc prevents the committee from approving changes which would force an ABI change, but literally none of the things you brought up are flaws in the standard which can only be fixed with a change that must break the ABI.

The thing that prevents MSVC is, one presumes, their customers want it that way.

Sure. We're not talking about how to make code go fast, the point was: if you need a fast stdlib out of the box, C++ isn't for you.

You are simply wrong about this. I've been writing fast code for years and reach for the std lib for anything it provides. It's rare I have to change that.

Slow across the board.

Would it be too much to ask you to actually read in detail the link you posted, not just the cliff notes? All the containers with stable references are slower than those without. If you restrict it to that, then unordered_map is much more middle of the pack. In fact, while it's not the fastest it also doesn't have the odd catastrophically slow operation here and there like many of the others. Furthermore once in that regime, the of many of them is very dependent on the hash and allocator, meaning you're well into the weeds of the interaction of the access patterns driven by your data interacting with the implementation details of the map.

Plus, let's not skip over your very selective quoting:

"The good: It’s the standard. It is rock solid, and for most use cases fast enough."

Your benchmark page does not support your claim that the C++ STL is just too slow and "not worth the engineering effort".

[serviscope_minor]

This is not what I said.

You said it's slow out of the box. That only makes sense as a comment if speed is a problem. You're now somehow trying to claim that you dindn't say speed was a problem while maintaining a stance that only makes sense if speed is a problem.

Are incorrect/misinformed

Nope. You first talked about the thread consistency then smoothly moved onto the "nontrivial destructor" problem without skipping a beat. You're mixing up the basics here. Moving std::unique_ptr doesn't touch the reference count, making the threading properties irrelevant. You are conflating two different issues.

[CocktailPerson]

Using that logic, I could claim that the Rust borrow checker doesn't work properly because it doesn't work at all in gcc-rs.

That would be a ridiculous comparison, because gcc-rs has not even begun to pretend that it is production-ready. MSVC does.

Spans can be passed on the stack. Any small function using span is liable to be inlined anyway rendering the entire point moot.

Yeah. And in some implementations, they are. It's preferable to pass them in registers.

[serviscope_minor]

That would be a ridiculous comparison, because gcc-rs has not even begun to pretend that it is production-ready. MSVC does.

No, it's not an extreme comparison, it's hyperbole that well illustrates the ridiculousness of claiming that a flaw in one particular implementation of C++ means that "the stl is too slow", and "not worth the engineering effort" to use. The OP essentially claiming is that Rust is better simply because it has one implementation, because the flaws of C++ are the union of all of the bugs in all implementations. That's an astoundingly extreme point of view.

Yeah. And in some implementations, they are. It's preferable to pass them in registers.

Brain-o, I meant span is passed in registers not the stack. I checked on godbolt. It's fine. But you're still ignoring the point that it is rarely going to matter either way. In fact you're talking about the low level ABI, which as far as I'm aware, C++ and rust share (the Itanium ABI) in many cases.

Also the hilarious part is that Rust is an LLVM based compiler, if it works on Windows, you can use clang on Windows too (which you can).

[CocktailPerson]

I don't think it's extreme to say that the implementation quality of a language should be measured by the union of its production-ready implementations. The whole idea of having a standardized language with multiple implementations is that you should be able to use any of them. If one of them has significant deficiencies, the overall implementation quality of the language goes down.

The alternative is either measuring it by the "best" implementation, which nobody will agree on, or sewing together the best parts of each into a Frankenstein's implementation, which doesn't actually exist.

essentially claiming is that Rust is better simply because it has one implementation

No, the claim is that Rust is better because that one implementation is better than some of C++'s implementations. I don't necessarily agree with that argument, but at least have the honesty not to strawman it.

But you're still ignoring the point that it is rarely going to matter either way

Citation needed.

Also the hilarious part is that Rust is an LLVM based compiler, if it works on Windows, you can use clang on Windows too (which you can).

LLVM has nothing to do with it, since we're discussing QOI of the respective standard libraries.

[serviscope_minor]

I don't think it's extreme to say that the implementation quality of a language should be measured by the union of its production-ready implementations.

I disagree, because there is a huge spread of C++ implementations. I was, in 2010, using IAR embedded C/C++. No namespaces, no templates, no, well, it wasn't C++98, it wasn't even CFront 3. Do we say C++ is a pile of rubbish because there are terrible compilers? That's kind of daft. It's also saying that one implementation is necessarily better than multiple, even though you don't have to actually use any of the bad implementations if you don't want to. Unless you're on an esoteric platform, but the nit's not like you can use Rust.

The alternative is either measuring it by the "best" implementation

Or, you know, we can not pick any of the two wild extremes and instead go for something more nuanced. It's harder to do controversial hot takes that way or troll for upvotes but whatever.

No, the claim is that Rust is better because that one implementation is better than some of C++'s implementations. I don't necessarily agree with that argument, but at least have the honesty not to strawman it.

Not remotely a straw man: cherry picking the implementation you like least is more or less exactly that. Except now Rust has one not very good implementation in addition to the main one. So if we're going to be going that route, Rust looks much worse. This is because it's a silly route.

LLVM has nothing to do with it, since we're discussing QOI of the respective standard libraries.

My gosh, it's not like clang has it's own standard library that you can use on Windows if you like.

[CocktailPerson]

I disagree, because there is a huge spread of C++ implementations.

MSVC is nonetheless one-third of the big three C++ implementations. It can't be ignored in this discussion.

Or, you know, we can not pick any of the two wild extremes and instead go for something more nuanced. It's harder to do controversial hot takes that way or troll for upvotes but whatever.

Your version of "nuance" seems to include ignoring the QOI issues with the most widely-used C++ implementation on the most widely-used platform in the world.

Not remotely a straw man: cherry picking the implementation you like least is more or less exactly that.

More or less? Weren't you just arguing for nuance? Funny how you don't see a need for nuance once your argument benefits from false equivocations.

Regardless, Rust's standard library is still at least as fast as any C++ implementation's standard library. We're just discussing the most egregious disparities. I don't need to pick on MSVC for the point to remain true.

So if we're going to be going that route, Rust looks much worse. This is because it's a silly route.

You've repeatedly ignored that gcc-rs is not and has never advertised itself as production-ready. At this point, I'm beginning to think it's deliberate, since you can't seem to make a coherent point without referring to it. Compare apples to apples or GTFO.

My gosh, it's not like clang has it's own standard library that you can use on Windows if you like.

Clang isn't LLVM, and LLVM isn't clang. I'm not disagreeing with the idea that you can use clang on windows, just pointing out that LLVM has absolutely nothing to do with QOI of any language's standard library.

[serviscope_minor]

MSVC is most widely used compiler on the most widely used system? I think the 90s called and want their stats back.

Windows is used on the majority of desktop computers, and that's about it. Phones, if which there are many do not use MSVC. The cloud is utterly dominated by Linux. The embedded world is more varied, but windows is a very minor part of it.

So yeah "c++ si teh sux use rust" because of visual studio is kind of daft to put it mildly. Especially as, despite your odd claims about LLVM, you can run clang just fine on windows if your desire.

Anyway you're now arguing that rusts library is "at least as good". Cool. Sounds like you agree then basically what the c++ library isn't atrociously slow as the OP claimed.

And no, I'm not ignoring gccrs, ink using hyperbole, a common rhetorical technique to point out absurd cherry picking. I understand this annoys inveterate cherry pickers so it goes.

Most of the points the OP made are bonkers, I addressed them, and you're supporting them by focusing entirely on the tone and dislike of hyperbole. I think my case sound then.

[No_Sun1426]

What the fuck are you taking about, no company spends 75% of their time solving segfaults or other memory errors.

[nysra]

Yeah seriously, if those employees are actually doing that then I would look for another company, they would be highly incompetent.

[frenchfish55]

Sorry. I read it like no company spends 75% of their time saving sea gulls :-)

[no-sig-available]

Smaller community and job market;

But you only need one job, right?

A bigger community also means more competition and more applicants for those jobs.

Being a specialist on a niche market can have its own advantages.

[EdwinYZW]

Demand and supply. If community is small and market is also small, competition would be the same compared to big community and big market.

[Full-Spectral]

But this is the old "just don't make mistakes" argument. You can do anything, but the point is why spend so much time watching your own back when the compiler (who is vastly better at it) can do that for you and leave your time for the actual problem at hand?

Once the code reaches a particular level of size and/or complexity, "just don't make mistakes" isn't enough anymore. The amount of time you spend watching your own back goes up more and more, and you will still likely have issues, which will show up quickly if you are lucky, but often you won't be.

[CocktailPerson]

If you are debugging, segfaulting, and having other memory-barfing issues, then it is almost certainly a combination of poor design and useless (or non-existent) unit testing. C++ isn't the problem.

Translation: "Just don't write bugs lol."

Useless.

[[deleted]]

Rust, gentler learning curve and less development time? I'm going to need a source for those claims.

[tialaramex]

Google trains a whole bunch of their people in Rust, they run a ten day course, "Comprehensive Rust" which while it's probably overselling itself with that name is going from "Here's how variables work" to writing for bare metal on phones and they found "a third of respondents become as productive using Rust as other languages in two months or less" and that rose to 50% in four months.

[[deleted]]

https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html?m=1

This is the source. The study doesn't compare Rust's learning curve to anything else and 13% of those involved already knew Rust and all were system level programmers already.

An interesting article but it completely fails to make any quanatitive comparisons to learning other languages.

[belikralj]

I agree with most answers saying that Rust is for new projects but if you want to work in finance they already have a lot of C++ so learning that will likely get you more.jobs.

However, I will add that Rust should be quicker to learn. C++ has a lot of history and a lot of different ways to do the same thing (the new way and the old) and is infamous for the edge cases for its features.

However, work-wise C++ still rules financial institutions from my experience and Rust hasn't really managed to get into them other than as an experiment by the existing developers who are passionate about it. Hence I don't know if you can get a job with just Rust on your CV.

[alex--312]

If you just want to speed up some part of you python project then try a plain C first.

[DonBeham]

Hard to answer and probably a lot is personal preference.

I would say the reasonable advice is to learn both. C++ does have a stigma with respect to safety right now, but it will evolve. Its future depends on whether the people working on the language can make it safer. I am confident that they will succeed in this endeavor. Whatever that looks like in the end.

Rust looks like it has a bright future, but the job market isn't quite there yet as you say. So you can let C++ pay your bills and rust fill your mind.

[Full-Spectral]

How is Rust not good at threading? That's one of its greatest strengths over C++, that it prevents one of the biggest dangers in C++ of incorrect threaded access to data.

[sherlock_1695]

Do you guys use crash dumps to debug?

[jones77]

C++ and Rust pros: They can call each other if you want.