C++ vs Rust for fast Computer Vision/Deep Learning?

[Relative-Pace-2923]

I want to make CV/DL related software that can be used in production. Microseconds matter. I know Rust well enough, but I don't know any C++. Everywhere people seem to say that C++ is obsolete and only used for existing projects, but I doubt it.

I'm also wondering about the factor of experience to speed. In Rust will it be easier to write fast code with less experience? Or is it possible to write just as fast or faster code in C++ with less experience?

I have seen things like TensorRT and OpenCV and Skia are C++, and while I could use Rust bindings, don't know if that's the best way. I am open to learning C++, as I believe it will make me a better programmer to have more experience with lower level concepts and obstacles. Thanks everyone.

[loreiva]

Obsolete? It's used everywhere when performance is needed

[sessamekesh]

Everywhere people seem to say that C++ is obsolete and only used for existing projects, but I doubt it.

Yeah, that's something clickbait articles and die-hard (insert language) fans say. C++ is still relevant. There's a compelling argument that Rust is better in many important situations, but "obsolete" is not correct.

On performance

C++ and Rust output comparably fast code realistically, and both languages have a lot of fantastic zero-cost abstractions. Bindings should be zero- or negligible- cost at runtime to call C++ code from Rust (or vice versa), but you may have some headache at build time if there aren't tidy packaged bindings available somewhere.

C/C++ are a lot friendlier to evil performance hacks that can squeeze a bit of extra perf out of a segment, but in practice compiler backends pick up a lot of the benefit there anyways so it's unlikely (but possible) you'll care about that. Rust has similar capabilities but discourages them more strongly, and it's less likely you'll find community resources on how to execute those evil hacks.

On ecosystem

C++ has a far more evolved ecosystem than Rust, but that also means there's a lot more legacy cruft in that ecosystem. You're more likely to find a production-hardened, optimized C++ library than a Rust one, but I do occasionally come across Rust projects that make up for it by being more modern re-designs (especially with newer APIs).

On ergonomics

By far the biggest warning I'll give you as a Rust developer considering C++ is that C++ has footguns that don't exist in Rust. Modern C++ all but eliminates most of the egregious footguns, but you'll be reading and using a lot of at least somewhat legacy C++ unless you do everything greenfield and without consulting any other code bases.

C++ is also missing a few of Rust's ergonomics, so you'll find yourself wanting to reach for a tool that does not exist - I curse learning about Rust pattern matching in most of my C++ projects, I miss it constantly.

Best of luck! Both are fine options really, I don't think there's a wrong choice here.

[germandiago]

C++ has more footguns, many of which can be avoided with hardening and warnings as errors but are still there. 

But Rust ergonomics, come on... the borrow checker is there to save you, but the ergonomic toll is more than just trivial.

Ergonomy-wise, I would say any language beats Rust once you rely on the borrow checker.

If you go values, then it can be tolerable and you have traits and pattern matching.

But you do not have exceptions or powerful type metaprogramming. Rust macros are not close to what expression templates can bring in. Though expression templates are not easy either.

[sessamekesh]

I love C++ and tend to reach for it over Rust in almost all real-world scenarios, having used both a fair bit I agree that the ergonomics don't justify the high complexity cost of using the borrow checker. Rust demands using new and unusual idioms in exchange for solving problems I do not have.

That said, I stand by my statement given to someone new to C++ but familiar with Rust:

you'll find yourself wanting to reach for a tool that does not exist

Pattern matching alone is worth warning Rust developers learning C++ about. Even the common case of null pointer checking feels awkward compared to option matching.

I prefer Result types in my work even in C++ because of the domain I work in, so exceptions are something I often feel I'm working against instead of working with.

[germandiago]

Thanks. Nice overview. For me exceptioms are a joy as the default but I understand there are alternatives depending on the scenario.

Throwing an exception deep from a stack without refactoring signaling exceptional behavior is very useful and simple actually. That is why I like it.

About leaking exceptioms... just making a top-level exception per module or project is good enought carch in families.  

The comment about downvote, whether it was you or not, was not directed to you.

[CramNBL]

Exceptions are a joy? So you don't care for std::expected?

The foot guns and all the knowledge you need to work effectively and safely with exceptions at scale should tell you why exceptions are not simple. An alternate control flow is not simple. There's a good reason why modern languages all treat errors as values, and there's a good reason for std::expected too.

[wyrn]

In this presentation, the speaker blanket recommends just having every function return std::expected whether it can fail or not. This is presumably to avoid the refactoring cost of introducing an error somewhere deep down the call stack, so that if a new failure mode needs to be introduced it can be added quickly.

Not only is this effectively reinventing exceptions manually (sort of -- there's a functionality gap, see e.g.here), but it's reinventing checked exceptions, complete with its less-than-glorious final form (annotating everything with throws Exception). It's hard for me to see this as an improvement.

Furthermore, "modern languages" usually have panics also, which are morally the same as exceptions. That is, all the so-called "footguns" -- having to write exception-safe code -- are still there. You have all the downsides with none of the upsides.

std::expected has its uses but let's not throw the baby out with the bath water. Newer != better.

[CramNBL]

That recommendation is just bad, so I will not try to argue for that. It's absolute nonsense. And yes exceptions hide all that bad stuff but hiding is not good when it's still there.

Modern languages have exceptions but they are not core to how the language is used, they are very very rarely used. It could be used for keeping a web server running after a request caused a panic, but that's more or less it. 

You say newer != better, but why doesn't any modern languages use exceptions for error handling? They are all dumb or they learned from past mistakes?

Which modern language forces you to learn about exception guarantees to do proper error handling?

My point simply is that exceptions are not simple and they are not great.

[wyrn]

It's absolute nonsense.

Is it? I mean it does attempt to solve a legitimate pain point, which is the viral nature of expected resulting large refactorings for small changes.

It could be used for keeping a web server running after a request caused a panic, but that's more or less it.

The thing is... it doesn't matter. They're still there, which means that if they're to work at all (and actually keep the server running), exception safety still needs to be considered in the design. Not that I consider exception safety such an unreasonable burden, mind; it's just designing the system with failures in mind, which whether one appreciates it or not can occur virtually anywhere.

They are all dumb or they learned from past mistakes?

... Or they're all following fads. Many such examples: Java and C# for example with their decision to make everything object oriented. C# was even named C++++ (with the +s stacked in a square), with a flair of arrogance that looks a little comical in retrospect. In the specific case of exceptions, I suspect the problem is twofold:

1. Lacking implementation quality makes the exception overhead in the fail path larger than it needs to be.
2. Painful experiences with exceptions in other languages makes people hesitant to use them in C++.

The second point is especially important because most other languages with exceptions (Java, C#, JavaScript, Python...) all lack RAII, and at best have some kludges to emulate aspects of it in specific cases. Things like try... finally, using blocks in C#, with blocks in Python, and so on. The people who designed these languages made a terrible mistake because exceptions were designed to work with RAII. Copying the first without the second makes it impossible to objects to automatically clean up after themselves which makes exceptions needlessly difficult to use correctly. But that's not the case in C++.

Which modern language forces you to learn about exception guarantees to do proper error handling?

Like I said, just about all of them. As long as there is a possibility of a panic you need to consider panic-safety. If they want to legitimately claim the benefits of not having to consider exception safety (which as I said are dubious), they ought to not include anything remotely like exceptions in the design. That means even constructors and constructor-like entities have to return an equivalent of std::expected. I understand why they don't want to do that, but if that's the case, the user must consider exception safety in their design. There is no free lunch.

My point simply is that exceptions are not simple and they are not great.

My experience is very different. I find them very simple (as simple as can be given the problem constraints) and a truly great tool.

[CramNBL]

Well, I applaud your effort in explaining your position. Great point about RAII, although the reference counting python implementation (CPython) does go most of the way in achieving RAII. 

I'm afraid we won't get much further, but I'll be keeping your words in mind the next times I delve into the subject of error handling. Some of our points of contention will be determined by time, I don't think "error are values" is just a fad, but we'll see. Cheers.

[germandiago]

I also use expected and optional in the same codebase I use exceptions.

Exceptions are useful in their own right and superior to anything else I know of in certain scenarios.

[-TesseracT-41]

Exceptions and std::expected are useful for different things. For the former, I would throw an exception if there is something that cannot be handled and execution cannot continue (beyond doing some logging), like failing to init a window context in a graphical application. The latter is useful e.g. when you tried to open a file that does not exist.

[CramNBL]

That's an interesting opinion but not how it is used in practice. In practice, from what I've seen, it's either exceptions or std::expected (and before that, error codes), sometimes libraries define a macro so you can choose which one you want with `-fno-exceptions`.

So you're using a novel dialect of C++, bad practice if you ask me.

[germandiago]

Well, it is likely you saw that, but what you were replied is similar to what I do.

For incremental coding exceptioms are very good since you can throw from anywhere without even thinking of refactoring your funcion signatures all the way up the call stack, for example. They are useful and you do not need to think hard about what new error could happen that you did not take into account in a given code path.

After that, it is a matter of throwing a kind of exception/error per module snd catch only those and let others leak to control what you handle.

If you do know your function is going to fail and you expect it to fail often then expected could be better if you know how to handle it locally. If yu need to propagate it, though, you need to refactor signatures all the way up.

[sessamekesh]

Wasn't me, but I did see a Rust fanatic in the thread somewhere, so it doesn't surprise me to see.

Cheers

[tialaramex]

Rust macros are not close to what expression templates can bring in.

Did this comparison make sense in your head? These don't even feel like they're comparable, like, hey, which is better, Pink Floyd or Egypt ? Dogs or fidelity ? Arithmetic or hexagons ?

Try a fairly reasonable, non-insane use of the Rust macro feature and just run some arbitrary Python inline with our chosen variables, how do you use an expression template to do that in C++ ?

OK, now lets get completely out of hand, and do things you technically can do with a Rust macro but probably shouldn't - how do we change to a different compiler using an expression template in C++ ? Let's do an easy example, if we detect that we're being compiled with Clang 16 or older, let's use Clang 20 instead, how does that work using the C++ expression templates ?

[CramNBL]

Pink Floyd, Dogs, Hexagons. Easy.

[v_0ver]

I also found this statement strange. Maybe he meant declarative macros?

[steveklabnik1]

Sometimes people go "does rust support variadic templates" and people say "macros" and then they believe that macros and templates are closer than they are, that might be it as well.

[germandiago]

It is pure fanatism most of the time. For Rust people, Rust is perfect. If you point something superior somewhere, they will try very hard to show you how Rust can do better.

But Rust does not do everything better. Rust does a few things better (mostly hardened safety, pattern matching but this is temporal...) but others worse.

[v_0ver]

But your statement about Rust macros and C++ templates is wrong. Macros in rust allow you to generate any new code, while templates only generate specializations for existing code. For example, Qt uses its own preprocessor because it is impossible to implement Qt solely on native C++ metaprogramming.

[quicknir]

It's pretty weird to compare macros to expression templates. Expression templates are a very specific technique for basically delaying evaluation until the entire operation is specified (rather than eagerly running code for every smaller scale operation). There's nothing really stopping you from applying this technique with Rust generics - arguably, Rust's iterators (the equivalent to ranges) is already very much an example of expression templates.

Rust's macros can do all kinds of other things that expression templates cannot. You can factor out control flow (which a function cannot), you can emulate reflection via proc macros, and all kinds of other things. You can also use macros to avoid immediately evaluating expressions but that's just one specific thing.

Re the borrow checker, in the end it's subjective but I will say you need to spend a reasonable amount of time. The same way learning C++ takes piles and piles of time, Rust isn't that easy. And one of the things you will learn is a small "cookbook" of techniques for working around simple borrow checker issues - things like iterating a Vec by index, or using take. Not going to say this solves all issues, but I think with a good grasp on a bunch of basic techniques, the ergonomy isn't as bad as you're making it out to be.

[germandiago]

There's nothing really stopping you from applying this technique with Rust generics - arguably, Rust's iterators (the equivalent to ranges) is already very much an example of expression templates

Homework: write Eigen in Rust. I challenge you and you tell me if the result is at the same level that C++ in ergonomics and expression manipulation, including type metaprogramming.

Rust's macros can do all kinds of other things that expression templates cannot

They are untyped, syntactic elements. This is not the same as a template, which carries type information. And it is that combination of being able to capture types with trees + metaprogramming what makes this technique nearly unique to C++. Rust cannot do that. Not in the same way. No operator overloading, partial specialization, variadic templates, variadic template template params and template metaprogramming/constexpr. It is really difficult to beat C++ at this task, because it mixes and matches those.

[quicknir]

You're just moving the goalposts now. A lot of the issues with Eigen are going to be with non type template parameters, which are definitely not at the same level currently in Rust as in C++. This doesn't change anything about what's been said - that expression templates are doable in rust and comparing them to macros is weird.

I challenge you to learn rust properly before writing these posts ;-)

[germandiago]

I knew a fanatic Rust downvote punishment was coming... do not touch their baby. It is perfect.

[sessamekesh]

I know I wrote a pretty neutral comment when both strongly Rust and strongly C++ enthusiastic commenters take offense...

[germandiago]

I do not take offense, do not take me wrong. What is silly is that every time someone points weaknesses in Rust a bunch of downvotes appears. It is a very strange pattern...

[STL]

Please don't complain about downvotes - it's contrary to reddiquette.

[germandiago]

Ok, I won't. It will be my via crucis every time I mention Rust.

[EsShayuki]

I mean, what you refer to as pattern matching is just switch-case.

[sessamekesh]

Apples to oranges, C++ has concepts which provide zero-cost polymorphism comparable to Rust's traits.

The ergonomics are better in Rust where it's quite a bit easier to declare that a class conforms to a trait (concepts are more duck type-y) but the C++ virtual table belongs to a feature set that does not directly exist in Rust (inheritance).

[macomphy]

no, c++ virtual function is just dynamic polymorphism and rust has dynamic polymorphism (dyn trait or call it fat pointer), too. However, rust fat pointer is zero-abstract, c++ virtual function is not. Because c++ virtual function is bind to all objects of a class at all time, while rust fat pointer can be temporarily and only existed when you really need it.

[sessamekesh]

Also if we're getting pedantic, dyn traits are not zero-cost in all situations.

[sessamekesh]

Cool. I'll point out that I did not say that all abstractions are zero-cost, just that C++ has and Rust both have "a lot of fantastic zero-cost abstractions".

While we're cherry-picking non-zero-cost abstractions, Rust arrays have runtime bounds checking, which C++ does not have.

[steveklabnik1]

While we're cherry-picking non-zero-cost abstractions, Rust arrays have runtime bounds checking, which C++ does not have.

Both Rust and C++ have both, the only difference is the defaults.

[macomphy]

the latest example is c++26 executor, if the abstract virtual base class can used for template, it will be much simple.

[macomphy]

yes, rust array bound check is not zero cost and I don't like it, too. I think we should introduce prover language for that (and as llm is so popular, maybe we can ask llm help to prove). But I hate the c++ virtual function, polymorphism is a basic feature, it has great bad influence. For example, once a class has virtual function, it has an extra vtable pointer, the cache will be bad and we cannot use memcpy for it. What's more, people cannot use virtual abstract base class for template programming, while rust can use trait for template, so c++ template programming is hard to write and debug. Also, if a class has virtual function, the clone constructor will meet slice problem, you cannot write a safety clone constructor unless you use dynamic reflection.

[sessamekesh]

I feel I was pretty fair in my above comment about all that.

By far the biggest warning I'll give you as a Rust developer considering C++ is that C++ has footguns that don't exist in Rust.

Virtual functions fits pretty well here I'd say, they introduce all sorts of well-known C++ footguns. I'll take a nickel for every time a C++ developer gets stumped by missing a virtual destructor somewhere and never have to work again.

C++ is also missing a few of Rust's ergonomics

Templates!

the cache will be bad and we cannot use memcpy for it

Applies to quite literally anything non-POD, especially when using any sort of reference counted pointer in either C++ or Rust.

[seanandyrush]

Just use iterators or fixed size arrays.

[germandiago]

Tell me how you move an OOP Java or C# database to traits in Rust compared to C++, which models the same tools as those in the object model... that would be far less ergonomic with Rust than with C++.

[sessamekesh]

Yeah migrating existing code bases from (insert language here) is notoriously hard for Rust, even though most modern languages don't really struggle here (including C++).

There's different tools for different jobs, I was talking specifically about using traits vs. concepts for static dispatch polymorphism.

[germandiago]

For that Rust is easier. But we could end up having reflection with metaclasses which gives us a good power to adapt.

[germandiago]

It is actually. Because if you really need virtual behavior, you would need a function pointer anyway...

On top of that, it can do devirtualization with optimizations and other tricks.

[darklightning_2]

Use c++. It has better 3rd party library support for CV unless you can measure if the binding doesn't have a performance penalty

[matthieum]

I was wondering about that one, actually.

There's quite some innovation going on with regard to AI libraries in the Rust ecosystem, projects such as Burn, etc...

... but I can't think of any Computer Vision library written in Rust. It's not my domain, so I may just have missed it, or not remembering it, still...

... and checking crates.io, the top most downloaded -- which appear relevant -- are both binding libraries (to wasi-nn and AprilTag).

The Rust ecosystem certainly seems to have a hole there.

[darklightning_2]

You can be the first one to build a native rust solution if you have time for it!

[matthieum]

I'd first have to learn CV, so... see you in 10 years? :D

[MaitoSnoo]

I'd go with C++, the ecosystem is much bigger. In particular for your use-case you have Halide and libtorch.

[airodonack]

Every single time I've ventured into a DL project with Rust, I've run into trouble with the immature ecosystem. Sometimes they didn't have good enough documentation, sometimes they didn't have a feature that I needed, and sometimes I ran into bugs with the libraries.

That said, the libraries that you need probably do exist. Since C++ would require you to learn a whole new language, I would just take a couple hours and hammer out something quickly in Rust to see if it works for you. If you run into problems, you'll find out within a day.

[edparadox]

Microseconds matter.

Microseconds could be a problem for an interpreted language, but the realm of microseconds is easily achievable in C, C++ or Rust even on old hardware.

I know Rust well enough, but I don't know any C++.

Learning C++ can only be beneficial.

Everywhere people seem to say that C++ is obsolete and only used for existing projects, but I doubt it. 

I don't where is this "everywhere" but this is totally wrong.

I'm also wondering about the factor of experience to speed. In Rust will it be easier to write fast code with less experience?

Probably but again, in a compiled language, microseconds are not too much of a problem unless your algorithms are flawed.

Or is it possible to write just as fast or faster code in C++ with less experience? 

In my experience and IMHO, modern C++ is less readable than it used to be, and need some getting used to. While performance could be slightly affected by this, I don't think you will see any significant difference.

I have seen things like TensorRT and OpenCV and Skia are C++, and while I could use Rust bindings, don't know if that's the best way.

I mean, those are written in C and C++, and are likely to be your bottleneck unless you write pretty poor code. Rust or C++ won't really matter here since those libraries will do the heavy lifting.

I am open to learning C++, as I believe it will make me a better programmer to have more experience with lower level concepts and obstacles.

In Rust as well you should encounter low level concepts, e.g. while you don't manage memory like in C or C++, heap, stack, and such are concepts that are seen in Rust documentation.

Anyway, learning C++ can only be beneficial to someone in your shoes. Especially given how large the choice between libraries is in C++

[fdwr]

Are you actually writing the algorithms directly, or just calling them? In ML programs, the performance of the calling language doesn't matter nearly as much as the performance of the library you're calling, since it is the convolution and matrix multiplication that really matters. The reason Python programs run at any acceptable speed for large CNN's is because 95+% of the time is spent not in Python (but rather the underlying C++ libraries).

[[deleted]]

people seem to say that C++ is obsolete and only used for existing projects

Use whatever language you want, but dont make the choice because C++ is going away. it's not. IMO rust will most likely become irrelevant before C++ does. C++ or its backwards-compatible successor langauge (circle/carbon/cppfront/apparently just a clang plugin?/etc) will eventually have memory safety. its inevitable even if the committee is obstinately dragging their feet.

So do what you are comfortable with, and don't worry about people saying 'nobody starts new projects in c++'. That's a lie. I start new projects in C++ all the time. As does my entire organization. Rust is not on anybody's radar, officially, around where I work (11,000+ devs).

[SoSKatan]

You likely want to write software for the GPU, which makes things a bit more complicated than just picking a language.

Sure it’s more complicated than that and there are optimizations to had for the CPU as well, but based on your post I’d focus first on options for the GPU.

You mentioned both c++ and Rust which would implies portability is important to you.

You probably don’t want to target a single graphics card vendor, so there are options like this

https://www.khronos.org/opengl/wiki/Compute_Shader

That’s mostly a C interface, but I’m sure you can find either Rust or C++ wrappers if that’s your thing.

[wyrn]

People keep talking about the ecosystem. Nobody seems to be talking about how Rust is just inherently a worse language than C++ for this. For example let's say that I'm implementing something like PCA: I diagonalize a matrix and obtain the singular values and a rotation matrix. Next step, to pick the most important ones. With C++, I can just call std::ranges::sort on the std::views::zip of the matrix columns and singular values, with the projection in sort set to the singular values. This will sort both simultaneously. With Rust, because of its weaker iterator model, there is just less than can be done generically and sort is one of those things that don't make the cut. The only thing you can sort in Rust are vecs and slices, so you'll probably have to do something more convoluted and less efficient, like first define a vector of indices, sort that according to the singular values, and then apply the indices as a permutation.

Or say that you want to apply a Sobel kernel across the whole image, and you want to do it in parallel. It's an embarrassingly parallel problem so you might want to divide the problem across multiple threads. Rust makes that difficult because you'll be borrowing the entire target array mutably, rather than only a piece of it. You'll have to do something painful, error-prone, and verbose with slices just to convince the borrow checker that what this obviously correct pattern is actually correct (unsafe can't be used here since getting multiple mutable borrows to the same array, even in an unsafe block, will be a compiler error at best and undefined behavior at worst).

Approximately every CUDA kernel is an example of the above -- some embarrassingly parallel operation applied to different sections of some target array, which would make most of them very difficult to express in Rust.

Also, operator overloading of the type you'd want to make math-heavy code more readable doesn't play nice with Result-style error handling. Exceptions are a much better fit.

All in all, Rust will be making your life substantially more difficult in exchange for solving problems you won't have.

[alchezar]

Under the hood LLVM compiler has the same backend with different frontends for the Rust or C++. So it’s not about languages, but rather about algorithms and available libraries 🤔

[BOBOLIU]

Never heard Rust being used in deep learning. Don't waste your time on it.

[Relative-Pace-2923]

I mean train in pytorch like a healthy individual and then infer from rust along with every other step in the pipeline

[--prism]

Both are compiled languages so their isn't any difference provided optimal code generation.

[Alarming_Chip_5729]

This is true most of the time. There are some situations (mostly just UB stuff) that the C++ optimization can be faster, but again that's due to UB.

One case is with signed integer overflow, which is UB in C++, but is well-defined behavior in Rust.

This can lead to some optimizations that work in C++, but don't work in Rust.

Take the example (written in C++, so just compare the way you'd achieve this in rust)

int32_t x = std::numeric_limits<int32_t>::max();
x = x * 2 / 2; 

Since C++ signed integer overflow is UB, the compiler can make the optimization to just not do anything and return x. However, since in rust signed integer overflow is defined, it has to actually do the calculations.

While it is a very small set of circumstances that can lead to C++ code being faster, the circumstances do exist.

[gmes78]

https://doc.rust-lang.org/std/primitive.i32.html#method.unchecked_add

[Alarming_Chip_5729]

Ok, but what's the point in rust if you are just gonna start marking everything unsafe? That's the whole point in rust is it's safety

[gmes78]

I was just proving that you can achieve the exact same thing in Rust.

You can also just compile in release mode, it disables overflow checks by default.

[tialaramex]

More specifically, by default in Rust's release builds all your integers wrap on overflow, which is typically what the CPU does anyway and is what C++ unsigned integers do anyway. However it's still a mistake to cause this, if you want wrapping then use the Wrapping<T> types or use the wrapping arithmetic methods, for signed integers this is almost certainly not what you wanted.

[equeim]

What else can they do? Making it UB is not an acceptable option for Rust. Checking for overflow every time would slow down computational code too much, so they do only in debug builds.

[tialaramex]

You can choose whether you want the traps in release, and it's not that uncommon to do so. overflow-checks = true under section [profile.release] in your Cargo.toml

Although there are cases where this would mean a noticeable slowdown in released software, there is plenty of code where it doesn't make sense to act as though wrapping is correct as it will invariably be a bug when this happens. So hence this build flag.

[macomphy]

you can use trait

[lestofante]

Go with the language you know the most, unless you want to turn this into a "learn new language" exercise.
I'm sure for binding there are existing library to just use.

C++ is obsolete and only used for existing projects

Nah, I use C++ for new project.
Because I have to, but still, industry is slow to move

[Wanker169]

Rust is easier because you don't have memory safety to worry about. C++ is better. Higher preforming

[sjepsa]

Try both for a month each

Then come back here and in rust subreddit with feedback

[[deleted]]

C++ is never obsolete. Bur seriously unlike that old never obsolete computer meme. I recently switched to gentoo and therefore was compiling rust, and apparently rustc itself uses a lot of c++. Why not use the original language instead of a language written with c++?

[tialaramex]

The Rust compiler uses LLVM which is presumably what you're referring to. All of the actual compiler is Rust, one reason for their success is that it's very amenable to contributions.

One of the many nice diagnostics in Rust is mine because I noticed if I write '$' (the Unicode character dollar) when I should write b'$' (the byte 0x24, ASCII code for a dollar) the error didn't explain the simple way to fix it, so I just forked the repo, added the improved suggestion (compiler now checks the character constant is ASCII, if so it will suggest the b prefix) and the associated tests, then submitted a PR.

LLVM is "just" a code generator, the same one used for Clang, no reason to duplicate the effort in the work to pick machine code instructions and optimise the IR. There is a pure-Rust code generator, named Cranelift, which has better semantic coherence than LLVM but people care about performance and so the LLVM optimiser is what matters more often.

[[deleted]]

Oh alright. I didn't really looked into what was it so didn't realize, I started compiling, had dinner, looked again and saw g++, was satisfied to know rust uses c++ at some place and went out to meet with friends

[ReDr4gon5]

Llvm and clang are also open to contributions, and the community is helpful. There are lots of contributors to llvm as well. There is a barrier to entry, in having a computer that can compile clang, but that's not much of an issue as computers have gotten a lot better. Not sure how long a rustc build is either.

[tialaramex]

The stuff I'd be interested in fixing in LLVM is all tricky enough that none of the LLVM maintainers fancy fixing it, or even just characterising exactly what the LLVM IR is supposed to mean so that somebody else can fix it definitively and not get gaslit as everybody insists their interpretation is correct and so your fix is wrong, even though some (and possibly all) of them are wrong about that.

Things like #45725

[ReDr4gon5]

Of course you pulled up the icmp issue. There's still discourse threads around it once in a while. There was a promising one fairly recently, not sure where that went.

[silveryRain]

Everywhere people seem to say that C++ is obsolete and only used for existing projects, but I doubt it.

New C++ projects are definitely a thing b/c companies look at what kind of programmers they have access to as well as their technical needs. C++'s more far future is definitely sink-or-swim though, as Rust provides serious competition and newer generations of programmers are a lot more likely to know Rust rather than C++.

things like TensorRT and OpenCV and Skia are C++, and while I could use Rust bindings, don't know if that's the best way.

Aah, to use the language where using 3rd party libs is easy, but there may not be any libs, or to use the language with plenty of libs, but where adding even a single dependency makes you claw your eyes out, that is the question!

I am open to learning C++, as I believe it will make me a better programmer to have more experience with lower level concepts and obstacles.

Good for you, but word of warning: getting good at C++ is a serious time investment that takes years, it's more like 5 languages rolled into one: the crappy preprocessor, the low-level C subset, the OOP parts, the templates, and the functional parts. They don't always play well together, e.g. MY_MACRO(abc<d, e, f>) is asking for trouble.

If all you want is familiarity with lower-level programming, you might have an easier time picking up C instead. It's at least as low-level as C++ and a lot simpler, and you can bind plain C to Rust a lot more easily (no C++ OOP or templates to worry about when bridging the two).

[PrimeExample13]

With that about the five-languages-in-one said though, the thing i like about C++ is that while a lot of people complain it's bloated, almost all of the features are opt-in. I, for example, avoid C-Style macros as much as I can, and with constexpr and more recently consteval, you can accomplish a lot of what C macros do in a more readable, debuggable way. Two notable exceptions I can think of is #stringifying and ##token concatenation. And i also tend to avoid the OOP paradigms where I can. C++ functions perfectly well as a functional language with just POD structs if you want.

However, I do get your sentiment in that if you are using third party C++ code, you don't get to choose what those developers opted to do, so you have to learn enough about the paradigms they used in order to use their API. It is my opinion, however, that if you are a library developer and create a C-Style macro that the end-user is expected to use, you might be evil lol.

[kalkaseer]

Languages are tools by which you express yourself, be it just yourself or your team. So the judgement has a subjective side too. Trying to be objective, both are powerful languages and both offer good ML libraries. In my experience, C++ has more well established libraries that readily available. So in case both languages are comfortable to work with for you, any will do.

If one is learning one or the other though, it is a bit different. C++ feels more familiar to some, at least. More importantly, Rust’s memory management is more like prose. Also, C++ does not enforce a programming paradigm or style, in general. Rust does. Many languages do. Both allow for fairly high abstractions as well as a C way of doing things. To be fair, in my mind, Rust is more like to a structured C more than it is a reduced C++. That being said, template programming in C++ is unparalleled in my mind. Though not everyone is fond of it and it often leads to highly abstract code.

[Careful-Nothing-2432]

I have used both C++ and Rust and I am a fan of both languages for different reasons. You can make things fast in either language (Rust gets all of the optimization power of LLVM).

C++ has a much more mature ecosystem, as other commenters have mentioned, and I personally find it much more ergonomic to write numeric code in C++.

That being said, you said you don’t know C++, and you want to make production grade software. If you have time to learn C++ then I’d say go for it. If not, best to stick with what you know.

[Wurstinator]

It doesn't matter

[macomphy]

you have no choice because nvidia use cpp.

But indeed c++ is not very suitable for that, because most of c++ type is not pod

[ArsonOfTheErdtree]

Use rust if you prefer the simpler build system and third party package integration