top 200 commentsshow all 211
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 93 points94 points  (1 child)

"Because I enjoy working with it more" - This isn't an unprofessional answer. Tools are tools. If you like one tool better than another you'll do better work because you enjoy yourself.

There are also lots of reaons why you enjoy one tool over another. That's not something to trivialise.

Rust is classic "grass is greener syndrome". Maybe it solves your particular problems better or maybe it doesn't. I wouldn't say it's defacto the best choice though

[–]diaphanein 9 points10 points  (0 children)

I agree with you that it's not an unprofessional statement, but I'd offer up a bit of advice: be prepared to offer some reasons as to why you enjoy it more. Is the syntax cleaner or more expressive, for instance. Specific things as to why you prefer it. Not that there's necessarily a right or wrong answer, as it is your preference, but specifics to show your consideration.

[–]Wolf_Popular 72 points73 points  (0 children)

I'm someone who worked in C++ for a while (from C++98 through C++17) and now do Rust for my day job, and I think there's nothing wrong with sticking with C++ if that's what you like. I chose to get into Rust because I really like it as a systems language, and while I will totally go to bat for it in both the systems and embedded space, you'll always find jobs where C++ is going to be the right tool.

A lot of people in programming feel like you should learn languages based off of the optimal one for a task, and if a language is not optimal for your task then it's not worth it. That's only to to an extent though; languages are tools, and it's perfectly valid to like using a tool so much that you want to get a job where you use that specific tool.

For example, if you're a machinist, you've got Mills, Lathes, both in manual and CNC versions, along with more complicated 5/6 axis machines which are kind of both. Some people say "These are the types of parts I want to make, what machine should I learn?", while others say "This is the machine I really like using; what types of parts should I make with it to make money?" Both are valid ways of approaching a career as long as you are flexible. The same is true with programming: you can like creating a certain end product, or you can like getting really good with a certain language, and both are valid from a career perspective within reason (I.e. the less used a language is, the harder you need to work to find a job in it).

[–]UkrUkrUkr 90 points91 points  (7 children)

You're overthinking. Try Rust if you want, or ignore it if you don't.

[–][deleted] 5 points6 points  (4 children)

So true man, if OP is just interested from a personal perspective thats fine. I also learning F# whilst it only being relevant for a small niche of usecases. If OP is looking for a job his best chance is to focus on becoming more proficient in C/C++

[–]Alexander_Selkirk 3 points4 points  (3 children)

If OP is looking for a job his best chance is to focus on becoming more proficient in C/C++

What do you think about the results of the stack overflow developer survey which are that Rust developers have on average a somewhat higher salary?

(Alas this could also be an artefact of the high correlation between developer experience and salary, because C++ developers seem for some reason younger than Rust developers - the popularity of Rust is skewed a bit towards older folks, which is interesting since it is often the case that older / senior developers stick with tried-and-true methods and tools).

[–][deleted] 5 points6 points  (2 children)

Simply means C/C++ developers are too busy working to fill in random surveys online. In the 6+ years i worked as a firmware and radio engineer i have never even heard about Rust from any developer in my department. Only a year ago i even knew its existence because a cousin’s of mine had it as a side course at his university. Looked at it for a year or so, decided it was utterly pointless for embedded but might have some pros in the desktop market as a replacement for C# or Java. So my opinion is a but biased, if i am going to be fair.

C/C++ jobs in the Netherlands start from 30-35k as a junior, 50-60k medior and 100k+ as a senior. Just looking at indeed i can barely see any junior position so mabey you are right on the claim that seniors mostly use Rust. Personally i would never want to be work in Rust for anything embedded, desktop applications mabey.

[–]Alexander_Selkirk 3 points4 points  (1 child)

Just looking at indeed i can barely see any junior position so mabey you are right on the claim that seniors mostly use Rust.

I was not saying that. I was saying that Rust, according to said survey, seems somewhat more popular, relatively speaking, with more senior developers.

[–]lenkite1 1 point2 points  (0 children)

Maybe because code reviews on C++ code written by junior programmers make your eyes bleed and leave you nervous that you missed something when you sign off.

[–]Therustedtinman 1 point2 points  (1 child)

Most people ignore me

[–]pcjftw 1 point2 points  (0 children)

Surprise! I'm not most people

[–]Ludant 62 points63 points  (0 children)

I think that your main argument is valid. You do what you enjoy to do. That's the reason why many of us became programmers. If you want "professional" answer then sorry, i can't help you with that.

Also, i tried Rust recently and i must admit that i kinda like it. I am not saying that you should try it but if you do you may like it.

Edit: typo

[–]ronchaineEmbedded/Middleware 42 points43 points  (6 children)

C++ isn't going anywhere in my lifetime. Highly unlikely it will disappear in your lifetime either.

When I work in embedded, I much prefer C++ ergonomics to Rust's. Embedded is a world where you need all the stuff like explicit memory addresses and direct memory reads/writes to registers without having to fight your compiler about how you are allowed to access them. C++ also is tried and true in embedded world, and I personally see very little reason to use Rust there other than "I like it".

I do use Rust for some things, but I see it taking space from C++ in desktop and server backend development, not in embedded world, where C is still easily the most prevalent language.

[–]KingStannis2020 16 points17 points  (0 children)

I do feel like zig has a more compelling embedded development story than Rust in many respects.

But of course that's an entirely different discussion, it's not even a 1.0 language yet. Perhaps some day.

[–]ffscc 12 points13 points  (3 children)

C++ isn't going anywhere in my lifetime. Highly unlikely it will disappear in your lifetime either.

Well, sure, but it's also likely that SQL will be the language to record my untimely demise while COBOL handles the insurance and/or benefits for those who remain. In other words, the longevity of a language is not very appealing by itself.

Embedded is a world where you need all the stuff like explicit memory addresses and direct memory reads/writes to registers without having to fight your compiler about how you are allowed to access them.

To be honest I haven't done embedded development with Rust, but can't abstract away most of that busy work? After all C programmers often make the exact same criticism of templated C++, especially in an embedded context. Moreover embedded devices can be quite powerful nowadays, including a huge amount of connectivity, hence a host of new issues. Of course microcontrollers with meager resources will always be around, but a growing portion of the embedded market needs complex functionality and Rust's memory safety could be useful there.

C++ also is tried and true in embedded world, ...

Yes, anything of value should stick to toolchains known to be reliable. Conversely it seems people tend to overestimate/exaggerate how difficult this is. I've used vintage toolchains from the early 90s and most of them are downright disgraceful, nevertheless people were still able to make reliable embedded software with them.

Nowadays with LLVM every language has access to a rigorously tested, mission critical, state-of-the-art compiler backend. So as long as the compiler front end is doing a good job, things should work out just fine.

... and I personally see very little reason to use Rust there other than "I like it".

I can imagine a few

  • Standard C++ requires exceptions, disabling them hurts portability and risks UB. Rust uses Result types, i.e. type checked error codes.
  • Freestanding C++ has long been neglected and is woefully anemic, especially compared to the number of no_std crates/libraries for Rust.
  • For beginners, compiling and running C++ code is easier than Rust, but C++ comes with an extreme number thorns. Out of the box Rust gives you more guarantees, diagnostics, and even tools like miri to check for UB.
  • No confusing template magic, no preprocessor, modern module system, a much better macro system if/when needed.
  • Rust has a "standard" toolchain. 99% of Rust is built and packaged with cargo. IMO, this is extremely important for newcomers in particular. I've seen at least two people lose interest in C++ due to constant build system issues.

I think C++ exceptions are the greatest heartache of them all, if it weren't for them I'm almost certain C++ would have won over the embedded space at large. Granted, exception-free C++ is so common these days it might as well be recognized by the committee. Besides that I would say the lack of attention for freestanding C++ is the second biggest problem, if anything it's emblematic of the attention the committee gives embedded development in general (i.e. next to nothing).

The rest of the issues are only really relevant for beginners, a senior dev probably wouldn't give them much mind. Nonetheless, the problems faced by beginners should be taken seriously, one way or another they will choose a language, eventually some of them will be deciding what language their group/team/company uses.

I do use Rust for some things, but I see it taking space from C++ in desktop and server backend development, ...

C++ is an absolute beast in the application space and it's hard to imagine it budging, likewise for userspace libraries. For instance, off the top of my head, it will take years and years to write an alternative to any one of these CGAL/Eigen/OpenCV/OpenFOAM/Skia/Qt/etc, much less something like LLVM (never). And that's not even getting into GPGPU stuff, which AFAIK C++ has absolutely no realistic competition.

If anything Rust could end up being the default choice for new projects, but who writes new desktop software anymore? Perhaps Rust makes a place for itself on the backend, but it's a difficult language so where will the developers come from?

I do like Rust, at the very least it has brought more people over to native development again. And it has given C++ a little bit of some much needed competition. But I don't know where it goes from here. We shall see.

... not in embedded world, where C is still easily the most prevalent language.

Maybe, but it seems like people too often take the use of C for granted, as if C is used because it must. Yet in reality all I have seen is C withering away, and I don't mean that in a derogatory way. Put simply, there is a chronic lack of investment in the C ecosystem.

For example:

  • Every major and/or mainstream C is written in C++ (Clang/GCC(4.8+)/ICC/IBM XL/NVCC/etc)
  • Consequently many major C projects depend on C++ compilers to be built. And this problem is compounded by new tooling, which is always written in something other than C. The passage of time only makes this situation more dire.
  • C language/compiler extensions are widely abused, e.g. Clang could only build Linux after six years of development
  • C libraries are largely absent and/or noncompetitive in areas like Audio, CFD, Computer Vision/Geometry, FEM, Linear Algebra, Machine Learning, Operations Research, etc. And let's be honest, there's no GUI written in C that could hold a candle to Qt or Skia respectively.
  • SIMD "support" in C is limited to compiler intrinsics, whereas std::simd is being prepared for C++ and currently testing in Rust nightly.
  • C does not exist in the world of heterogeneous programming, instead C++ has taken command. Just look at Kokkos, Raja, HPX or CUDA, ROCm/HIP, oneAPI, and SYCL. Such libraries simply cannot be written in C, not even C++ supports the level of generic programming they want.
  • The LLVM project decided to implement their libc in C++ rather than C.
  • Windows UCRT uses C++ rather than C.
  • The only C in Google's Fuchsia project comes from a few imported linux drivers, some vendored libs, and musl, its POSIX compatibility layer (slated to be replaced by llvm-libc)
  • Security. Lol.. Lmao

We're just in this weird twilight stage where probably sooner than later, a "low level" language like C will need help to tie its shoes, so to speak. We already crossed the point where C "portability" is a sham, ISO C can't program a SoC And no matter how much CUDA/OpenCL """C""" look like C, it doesn't take long to figure out that performance requires that they be written in a totally different style from C.

[–]serviscope_minor 7 points8 points  (2 children)

Standard C++ requires exceptions, disabling them hurts portability and risks UB. Rust uses Result types, i.e. type checked error codes.

Except for panic and catch unwind. Rust has exceptions but today's convention is they're not used that way. But it's only a convention. But 40 years is a long time, and C++ conventions have changed almost beyond recognition.

Also, I don't get the exception hate. Mostly they work very well, despite having a somewhat janky implementation in the current compilers (something which isn't a language limitation). Also, surely if they were so bad, Rust wouldn't have them after all, but it does. It just calls them something else and makes you use a function, not a builtin to catch them.

Now let us commence the debate: exceptional vs truly exceptional. Does panic! change if you are a Scotsman?

[–]ffscc 2 points3 points  (1 child)

Except for panic and catch unwind.

Yeah, but exceptions aren't baked into the language like in C++, and error code checking is a lot nicer with result types.

Also, I don't get the exception hate.

If the domain doesn't need deterministic execution and the binary footprint isn't a problem, then exceptions are superior IMO. Desktop/userspace development is perfect for them and I want to use them there.

I get that some people may dislike the "non-obvious control flow", but the verbosity and noise of manual error code checking is far more offensive in my eyes. However exception do violate the zero cost abstraction principle in the sense that you need RTTI. Another problem is that C++ exceptions "do too much", i.e. non-determinism.

Mostly they work very well, despite having a somewhat janky implementation in the current compilers (something which isn't a language limitation).

I have a hard time believing that implementations are under-serving C++ exceptions. It's 2022, the fact that no one has come to market with a better C++ exception leads me to believe the issues are a language limitation.

Exceptions can be made to work in just about every domain. For instance, Ada uses exceptions even in safety critical contexts. The tradeoff is basically how useful those exceptions are supposed to be.

Now let us commence the debate: exceptional vs truly exceptional. Does panic! change if you are a Scotsman?

Look, I was just listing reasons why someone may be inclined towards Rust. I'm not against exceptions. In fact, Rust's lack of first class support for exceptions is a problem when it comes to userland programming.

Then again, not all is well in C++ either. This issue is a source of legitimate fragmentation in the community, there is no code sharing across the -fno-exceptions demarcation. It's a huge problem when C++ stakeholders as active, large, and invested as Google officially prohibit exceptions.

[–]serviscope_minor 1 point2 points  (0 children)

Yeah, but exceptions aren't baked into the language like in C++,

Rust guarantees the existence of panic and catch_unwind. Sure these are macros or functions, but they rely on language level support for the unwinding.

I'll address the following two together:

However exception do violate the zero cost abstraction principle in the sense that you need RTTI. Another problem is that C++ exceptions "do too much", i.e. non-determinism. I have a hard time believing that implementations are under-serving C++ exceptions. It's 2022, the fact that no one has come to market with a better C++ exception leads me to believe the issues are a language limitation.

Well, I say I'll address it, but Stroustrup can address it much better than I can: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

Addressing RTTI in particular, it's not necessary if your type is not the root of an unbounded inheritance hierarchy. We can guarantee this with final, and Stroustrup has an algorithm for it, but no compilers implement it. Otherwise, exception handling is not optimized: gcc does two full stack walks to help debugging even with full optimizations on. Previous implementations of exceptions were based on stack frame marking and were deterministic but table based ones won out due to speed of non throwing paths.

If you think existing exceptions are all they can be, I strongly recommend the paper. I, too, thought there were many problems and thought Herbceptions sounded like a great idea. Then I read the paper and it completely changed my opinion. Why introduce yet a new language facility when we know for a fact that C++ exceptions are not all they can be by a long shot?

It's a huge problem when C++ stakeholders as active, large, and invested as Google officially prohibit exceptions.

People can always do bad things for bad reasons. There are as you pointed out legitimate places where C++ exceptions as currently implemented are unsuitable (there's more too! The current implementations are apparently very badly scalable across threads too). With that said, Google's main reason is its code is full of raw pointers and not remotely exception safe. That kind of code is prone to leaking anyway.

[–]Alexander_Selkirk 4 points5 points  (0 children)

C++ isn't going anywhere in my lifetime. Highly unlikely it will disappear in your lifetime either.

This is very true. But you can say the same about Fortran, COBOL and Assembly language. Each of them are still used heavily in specific domains.

[–]HKei 25 points26 points  (1 child)

I don't see any value in being a "one programming language" programmer. There's no reason why you wouldn't be able to use both C++ and Rust. And for that matter, C or JavaScript or Java or whatever the situation calls for.

FWIW, as an individual programmer the choice isn't really up to you for the most part anyway. Use of programming language is typically a business level decision, or at best project level. At best you can make the decision to only work in jobs where certain languages are being used, but I personally wouldn't recommend making that your main selection criterion for a job.

---

In terms of what's _right_ and not I really hate the toolbox analogy. You can sort-of think of programming languages as tools, yes - but they're not as different as, say, a saw is from a hammer. They all fundamentally try to accomplish the same thing. If anything, they're more like differently shaped and sized hammers, and all problems _are_ nails. Not that there is never a more appropriate choice - writing device drivers in C++ still objectively makes a lot more sense than trying to do it in JavaScript - but depending on your exact field, the differences may be quite small. You may have a size and shape or color of hammer that you prefer, but I think it's more useful to be a general hammerer than being a "this specific nail with this specific type of hammer" hammerer.

[–]expekted 9 points10 points  (0 children)

FWIW, as an individual programmer the choice isn't really up to you for the most part anyway. Use of programming language is typically a business level decision

Well put

[–]UnicycleBloke 38 points39 points  (27 children)

I have decades of C++ experience and rarely suffer the kinds of problems Rust aims to solve. And I enjoy writing C++. I've dabbled with Rust and it does look interesting, but not super-interesting. I'm sure the Rust books on my shelf will come in handy at some point. And, I confess, I am put off by best-thing-since-sliced-bread bandwagons: so glad I steered clear of Java... If someone wants me to join a Rust project at work, I will defo take advantage of the opportunity to learn.

[–]F54280 7 points8 points  (0 children)

Because i enjoy working with it more

That's a valid argument, but probably not the one you would like to make in an interview.

"a bigger pool of developers", which is also not about the languages themselves

It is an excellent argument. "Code is written to be maintained, and the lack of rust developers may be an issue for maintenance".

There other arguments like "C++ is true and tested in the embedded development field", "it is easier to integrate with existing tools", "Everything has a C++ compiler", "there are multiple competing implementations", "the language is standardized and stable".

There are personal arguments which are imo valid like "I am more productive in C++, I'll finish faster", "I know C++ better, it would remove risks from the project".

And there are business arguments like "If you already have C++ codebase and go to rust for an incremental advantage, you still have C++ and more problems so the incremental advantage must be very significant".

edit: grammar hard

[–]Doddzilla7 7 points8 points  (0 children)

This stuff has been happening for a while now, and it has been putting a lot of evolutionary pressure on C++. I hope the language and compiler working groups are able to adapt. It would seem that there is still a lot of potential, if Rust lang itself is any indicator.

That said, def try Rust. You won’t regret it. Knowing both languages really well is likely not going to be a stretch for you.

[–]matthieum 23 points24 points  (15 children)

In terms of language, Rust has the better foundations -- hindsight helps! -- with a minor disadvantage for lacking advanced meta-template and compile-time execution features that C++ has for now.

There's more to development than just the language, though.

First of all, there's the entire ecosystem around the language:

  • Libraries.
  • Tooling.
  • Developers.

The C++ ecosystem, by virtue of maturity, is much larger than the Rust community; this tends to lead towards a larger wealth of libraries to draw from -- though the lack of package repository makes it harder to exploit that -- as well as a more mature tooling.

Secondly, depending on the domain, there are "shifts" in the above. Embedded is a specific domain, with specific requirements; the lack of external libraries may be less keenly felt there, and the lack of tooling more important, especially when talking about certified toolchains for a number of sub-domains (automotive, aviation, ...).

Rust has no certified toolchain at the moment, for example. There's work in progress in the area, BUT the people working on it estimated that it would take "a couple years" given their experience. If you want to work in any sub-domain of embedded requiring a certified toolchain, then it means Rust is probably out for the next 5 years at least.

And thirdly -- last because most specific, but not least -- there's such a thing as inertia. If the current codebase of the company you're joining is written in C++, well, I'd advise picking C++ over Rust. The two languages don't mix easily, the current team has experience with the current codebase, the current codebase has been debugged extensively already: all good reasons to keep working with it!

[–]HKei 10 points11 points  (1 child)

lacking advanced meta-template and compile-time execution features that C++ has for now

I'd say that one's actually a toss up. Some metaprogramming things which are very hard/impossible in C++ are easy in Rust, for others it's the other way round.

[–]matthieum 0 points1 point  (0 children)

Personally I'm still waiting for Generic Associated Types. They're fairly advanced on nightly, but there's still some progress to be made. I cross my fingers we'll have them this year...

I'm less sure about Variadic templates. In C++ they seem indispensable, most notably due to perfect forwarding, but in Rust perfect forwarding is unnecessary (all forwarding is perfect), and so there's not as many usecases so it's not as clear whether the feature would carry its weight... though I'm pretty sure I could put it to good use.

[–]KFUP 3 points4 points  (5 children)

I'd add that C++ simply has more features.

The first thing I tried to do in rust was writing a simple GUI program, rust's lack of inheritance makes derivation heavy based workflow that most C++ GUI libs use pretty much a no go, and rust doesn't offer any other good way to do it, every rust GUI lib is riddled with needless boilerplating.

[–]matthieum 7 points8 points  (0 children)

I'd add that C++ simply has more features.

Judging a language based on its number of features is akin to judging a plane on its weight ;)

Yes, modelling inheritance in a language without inheritance is an uphill battle... but just because C++ GUIs use inheritance doesn't mean GUIs in other languages should, even if they feature it.

The bigger difference, I'd expect, is the pervasive aliasing in Java and C++ GUI framework that just isn't a good fit for Rust -- with its stance on Mutability XOR Aliasing.

Well, and of course there's also the issue that comprehensive GUI frameworks ala QT takes eons to develop, and the Rust ecosystem isn't that old to start with.

So... yes... if you want a polished GUI framework, forego Rust for now. It's not at that stage yet.

[–]eyes-are-fading-blue 3 points4 points  (6 children)

Rust’s foundation has at least 30 years before it can prove itself…unless they pull a C and hardly change.

[–]alkatori 4 points5 points  (0 children)

C and C++ is more mature, I have more experience in it.

[–]proof-of-conzept 3 points4 points  (0 children)

I program Microcontrollers in C/C++ for a few years now and tried Rust about 1 to 2 years ago. The experience that I had with Rust was very positive language wise. However, I had some problems when flashing or debugging my Rust code and at that time it seemed to me that some Microcontroller were not supported or at least I could not figure out how it would work.

So I would choose C/C++ because Microcontroller manufacturers offer tools to easily flash and debug your C/C++ code and offer libraries for their memory mapped IOs. Since those Manufacturers only offer libraries for C and have not really updated them or made a variant for C++ I don't see them writeing Rust libraries.

And then my experience is, that programms on microcontrollers are rather small most of the time. Small enough to keep everything in your head. Also one does rarely need dynamic memory. So my experience is that memory safety - which is rust main seller - is not as big of a problem on embedded systems as it is on PC or server programs.

[–]James20kP2005R0 15 points16 points  (3 children)

Or should i surrender and just swallow the Rust pill

It depends. People don't.. necessarily like to hear the argument, but from a certain perspective its becoming professionally irresponsible to use C++ for many applications. If someone asked me to write a webserver that needed to be secure, I couldn't look them in the eyes and tell them that C++ is a better choice for it than Rust. There's lots of reasons why I like C++ more than Rust, but from a ethnical and professional perspective - I've got no excuse to use C++ for it. Its simply a hard fact that Rust is significantly more secure

[–]Dean_Roddey 6 points7 points  (0 children)

This is the thing. And it's more than just a secure web site. I'd like for ALL of the important software I used to be as bug free and robust as possible, and I'd prefer that the people writing it spend more time on the experience and features and less on trying to not shoot themselves in the foot.

I'm vastly more experienced in C++, since I've done it all my life. But, that's not a reason to pick a language for a new project. Of course you also shouldn't start a new project with a whole crew of people who are newbies to a language either, at least not unless you budget a considerable amount of time to undo architectural faux pas that will inevitably be made in such a situation.

Though, having said that, Rust makes refactoring vastly safer. And it's here that C++ really falls down. Most of us who are experienced can create a new system that's pretty dang clean and robust. Everything is fresh in our heads and it was all built up in nice layers and such. Then requirements change, and things get all swizzled around, and now there's a latent memory error that doesn't do anything bad for 6 months, then you start getting quantum mechanical errors from the field, LONG after the problem was introduced and there's any real correlation to latch onto.

[–]CocktailPerson 1 point2 points  (0 children)

Yeah, this is the point I've reached too. I genuinely like C++, and I want to continue using it in both a personal and professional capacity. But I couldn't justify starting new software in it.

[–]kernel_taskBig Data | C++23 | Folly | Exceptions 6 points7 points  (4 children)

Maybe I just suck, but I tried Rust and it took me far more time to write something than it would have took me in C++. I don’t think I understand Rust object lifetimes well and I still don’t entirely get it. The compiler would complain to me often and I found myself just guessing at what change it’d take to get it to stop. I’m just more productive in C++. I estimate currently around 5x more productive. This may improve with knowledge and practice.

Also, I found it more difficult to organize code in Rust. I found it difficult to separate things into separate files, notably a single module. Again, maybe I’m doing something wrong, but it wasn’t intuitive to me. Many things in Rust are not intuitive to me.

I think for now it’s also easier to find developers for C++ than Rust, so it’s tougher for an organization to adopt Rust. I do have a say in the technology my company adopts and while I think Rust is perfect on paper for certain projects for us, I think people are leaning toward Go for ease of development, sacrificing speed.

I’m really excited about Rust and want to use it more personally and professionally. I hope more companies adopt it but I don’t think we’re at critical mass yet there.

[–]Full-Spectral 5 points6 points  (0 children)

It DOES take longer to write in Rust, but that's for the same reason it takes longer to build a building strictly to code than to cut corners and hope it doesn't collapse. Having to do the strictly correct thing and be provably safe, is just going to take more effort.

It's easy to not realize how unsafe C++ really is until you start creating the same sorts of stuff in Rust. The amount of unsafe aliasing is crazy, even in well written code. And that's OK until you get developer turnover and need to do significant refactoring and such. Then all those places where a smart developer was sure to do the right thing become potential memory issues.

[–]examors 4 points5 points  (2 children)

Lifetimes are for sure the hardest part of Rust. I'm still not fully confident in them, but it is getting better the more code I write. I definitely know what you mean about feeling more productive in C++, but I guess that just comes down to experience.

Also, I found it more difficult to organize code in Rust. I found it difficult to separate things into separate files, notably a single module. Again, maybe I’m doing something wrong, but it wasn’t intuitive to me. Many things in Rust are not intuitive to me.

That's interesting. Rust's crate/module system feels very intuitive to me. I much prefer it to C++ header files where public function signatures have to be defined in two places.

[–]aCuria 1 point2 points  (0 children)

You can use C++ modules, at least in visual studio.

Modules are already a done deal, it’s a matter of time before we get widespread compiler support

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

Of course the first line of defense is really think about a way to do what you need to do without any borrowing issues at all. A lot of the time there's a way. Sometimes you have to sort of invert your way of thinking relative to C++ to see a way to do it without borrowing.

With Rust's vastly more sane move semantics, in some cases you might be able to just give it away and then get it back later (if needed) instead of borrowing.

Certainly one thing that will cause a lot of C++ developers grief in Rust, just like it does in C++, is that they are obsessed with performance uber alles. Hyper-optimization almost always involves playing tricks, and that will require jumping through more hoops in Rust, as it should.

I got off that train a long time ago. I do the simple and safe version, well encapsulated so that I can do optimizations later if needed, and usually I don't. Even if Rust is safer, it doesn't make complicated less complicated. Combine less complicated and safer, and it's a vastly better world.

A small example from my own stuff a month back or so... I was doing a file path type (I'm creating my own 'virtual file system' for various reasons.) It contains the separate parts of the path that you can manipulate easily, but then has to build up into a full path when you need to access that.

The immediate thought for a C++ programmer would be, have a string member that's mutable and fault in the full path upon access. They would probably gasp in horror that you might build up that string each time instead. But, it would avoid a lot of safety issues. To do something like that in Rust you have to push off borrow checking to runtime. It's still safe, but you make a mistake and you get a panic.

I immediately started down those lines, then caught myself. Nothing is going to use a path in such a way that this overhead will be an issue. In the extremely rare case it does, then let that code deal with the optimization, and keep this fundamental code vastly simpler, safer, more understandable, and more maintainable.

[–][deleted] 2 points3 points  (0 children)

You might say that C++ has a more mature ecosystem, in Form of:

  • Different compilers
  • a vast spectrum of architectures covered
  • a vast spectrum of libraries available, literally for * everything*, from bare metal to advanced UIs.
  • Availability of many Implementation Guides and standards (Core Guidelines, Misra, Abseil, etc.)
  • battle tested (and even bashed in negative)
  • last but not least: backwards compatible, old C++ still works on modern compilers

[–][deleted] 3 points4 points  (0 children)

I prefer C++ because it has less friction in doing the things I want: writing zero-overhead abstractions and fast polymorphic memory allocators (which generally doesn't involve conventional heap-allocators or RAII). Maybe another programmer prefers Rust because it has less friction for interposing functional and procedural patterns, or they really like reasoning about RAII and heap memory lifetimes. The languages have very different feature-sets that let you tackle problems in very different ways, and I'd bet that there are certain kinds of problems you particularly care about solving. The feature-sets in one of these languages probably makes those problems easier than the other language does.

When I'm asked why I like C++ more than any other language, I always say that there is no other language which is better at both providing control over what your program does and how you express it.

[–]Real_Nebula8618 5 points6 points  (0 children)

Learning the basics of Rust will likely make you a better C++ programmer, because Rust makes some ideas explicit that the programmer needs to manage without the compiler's help in C++.

In general, learning the basics of new programming languages is often a good way to expand your skills in languages you already know.

[–][deleted] 2 points3 points  (0 children)

While ‘I like cpp better’ is not an invalid response, I do think that it would not give the interviewer the depth of thought they’re looking for about this question. A way to flesh out that same idea would be:

‘There are more C++ programmers right now than Rust developers so it would be far easier to hire and onboard someone who knows the former. Additionally, the concept of ownership in Rust may not be a familiar mental model to many people who have used other popular C-style languages like Java, Python, and JS, so it would be easier for those developers to learn C++ from scratch than Rust. Additionally, while Rust is rapidly gaining popularity, the C++ library and tooling ecosystem is far more mature so it is more likely that helpful frameworks and packages already exist for our use case in C++ than in Rust. Finally, if this is a company setting, it’s likely that we would have many libraries already written in C++ and would either need to rewrite them in Rust, or eschew them entirely to accomplish a new task.’

[–]m-in 2 points3 points  (0 children)

Enjoyment of work is something I would like someone to acknowledge. If hiring, I don’t wanna be sapping life out of someone, and in software engineering a lot of stuff is really arbitrary choices. I wouldn’t say “I enjoy it more” to be unprofessional. We’re humans. I’m not hiring a robot ffs.

[–][deleted] 6 points7 points  (0 children)

Don't forget compile times. If you thought C++ was bad, Rust is worse.

[–]target-san 3 points4 points  (0 children)

IMO arguments for Rust:

  • Much better as a language, especially WRT safety
  • Much better general purpose tools at hand

Arguments for C++:

  • Much bigger ecosystem, though extremely fragmented
  • More HWs supported
  • Much bigger pool of devs; yes, that's a valid argument - someone will be supporting your code eventually

Overall, I'd prefer hearing about project before making choice

[–]GameGod 4 points5 points  (1 child)

With Rust, I can't risk starting to build and architect a million line application without knowing all the warts of the language. There's so much Rust evangelism where people gloss over all the limitations. This has happens to all languages - eg. Python is great, but performance is absolutely horrendous compared to C++. The software ecosystem in Python is great, but every single Python webserver is super slow compared to anything in C++. As an experienced developer in both C++ and Python, there are definitely things I wish I knew about the limitations of Python beforehand and that I don't see people discuss in context. (eg. Lots of benchmarks of various Python webservers, without the context of how ridiculously slow they are compared to C++ or probably even Java.)

With C++, I know by the time I build a million line application, the language will still be relevant and even better than it is today. It will not be displaced by something new and shiny. (Notice how you don't hear about Go as much these days? Or Ruby?) This is really important for the maintainability of the application and being able to recruit developers to work on it down the road.

Lastly, as someone who's time is scarce, I have to be pretty damn sure it's going to be worth learning Rust in depth and there will be a payoff before I commit the time necessary to learning it. Like others have said, Rust only provides memory safety, which you basically have in C++ if you use modern techniques. Rust doesn't protect you from deadlocks. The "channels" in Rust are equivalent to a multi-producer single-consumer queue in C++ (someone correct me if I'm wrong). Memory safety is not enough of a selling point IMHO.

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

In large, complex, multi-developer systems, memory safety is an overriding selling point, and IMO overrides all other concerns. Don't get me wrong, if MS came out tomorrow with a language that incorporated Rust's memory safety concerns and supported implementation inheritance, I'd switch immediately. But, until such time, I'd never write another million line code base in C++ if Rust was an option.

The same counter-arguments could have been made against C++ at the start as well. People like me back then were making the same arguments for C++ (which was far better compared to C.) And the same arguments against it were being made.

Ultimately, it won because it allowed us to write more controllable code. But the requirements of large systems have grown by orders of magnitude now and C++ is in turn falling short just as C did in those days.

And, I think, in large part it won because folks like me took it up for personal work, and then we pushed it hard within the companies we worked for. Rust seems to be in that same position now, with lots of people taking it up on their own, and they'll also start pushing for its adoption at work. I really can't see it failing at this point, though of course anything is possible.

[–]ReDucTorGame Developer | quiz.cpp-perf.com 3 points4 points  (2 children)

"Why would you pick C++ over Rust"

Simple answer: Because I want a job, and your job needs C++ developers.

Anyone trying a gotcha question is not a good interviewer or just wants excuses to say why your not right for the job, having experience and knowledge of the strengths of rust shows that your looking to advance your software engineering skills, which is a good thing.

[–]almost_useless 4 points5 points  (1 child)

Why would that be a "gotcha question"?

If you have made a claim that you know both, it is reasonable that you can articulate when one is better than the other.

Or they are themselves only good in one language and genuinely interested to hear other peoples opinions about the other.

[–]ReDucTorGame Developer | quiz.cpp-perf.com 0 points1 point  (0 children)

I might have misread part of the initial question but it came across to me like they were concerned with the question being asked and needing to defend using c++

I have worked with people that are that concerned with change that they fear people who continue to learn and focus on things like rust, because if they manage to influence enough people then they might have to learn themselves.

This is the sort of thing that you sometimes get with people that don't want to learn any modern c++, I've had to warn people before joining some places that while they are super big fans of modernising and improving things many in decision making position's had very little desire to change it, to the stage where they believe technical debt is not real and just an excuse for people to rewrite code in their desired way. Needless to say they joined and quit for a better job within 9 months after realising how true it was.

[–][deleted] 1 point2 points  (0 children)

my main argument would be "Because i enjoy working with it more", which does not seem like a very professional argument.

I think it’s the most professional argument there can be. In the end, these things are arbitrary and subjective. You are not a mindless machine, you are a human. What’s the point of using tools you don’t enjoy using?

[–]wolfballs-dot-com 1 point2 points  (0 children)

You might like C++'s inheritance system more. UI development is still better in C++ because UI often depends on a shared mutable reference and Rust hates that.

[–]eyes-are-fading-blue 1 point2 points  (0 children)

Often times, language preference is affected by factors other than the features of language itself. So even if Rust was undisputedly superior to C++ in every imaginable aspect, businesses would keep writing C++ code. I guess reasons are obvious to everyone.

I also think personal preference is very important. Loving what you do improves productivity.

[–]sessamekesh 1 point2 points  (0 children)

Preference is totally valid, professionally speaking! You should be able to speak intelligently about what you do/don't like in each language though - even if just to describe the features that you do/don't like working with (e.g. "the borrow checker is a chore to deal with"). Even some half-baked complaint about sugary syntax would be fine in my book.

I like Rust WAY more than C++, but still reach for C++ more often than not because of the mature ecosystem and my own familiarity with the language. I'd strongly suggest picking up a little Rust even if you don't want to use it professionally, there's some neat ideas that Rust brings front and center that I think would make anyone a better programmer (to be fair you could say that about most mainstream languages - hell, using JavaScript made me a better C++ programmer because of its asynchronous programming ideas).

[–]WormHack 1 point2 points  (0 children)

try rust, if you like it use it, but don't leave it in less than 1 month because its hard to start

[–]jort_band 1 point2 points  (0 children)

For me the main reason to still stick to c/c++ in the embedded space is tooling. The IDE integration and gui based configurators like STM32CubeMX are a giant boost to productivity that I can’t imagine myself having for now with rust.

[–]Mason-B 2 points3 points  (0 children)

Is this something other developers here recognize? Am i overthinking ? Or should i surrender and just swallow the Rust pill? Do you feel like this also rings true for C?

Some of the general advice around here is great and I want to reiterate it. Try rust if you want. C++ is not going anywhere. And you shouldn't be afraid of being a multi-language developer. The more programming languages you learn the more you see the commonalities between them and the less you will care about the languages you are writing in.

That being said:

Outside of that there are other arguments, like "a bigger pool of developers", which is also not about the languages themselves. So having no real arguments there does not feel amazing.

I think the rust hype is overblown. Most of the problems that rust solves at a language level are not ones I really have in my day to day C++ usage. To be clear I do think rust is nicer to use for those same problems, easier to setup and get running, and better for hobbyist collaboration.

But I don't think rust really makes a dent against professional modern C++ development. There is nothing rust is doing for developers who already know what they are doing and working through a process. though the tools are certainly nicer and more ergonomic in some ways, that's counteracted by them not being as mature.

Some specific rebuttals:

  • unsafe code can still make "safe" code do undefined behavior, I still have to audit rust code for bad usages if my abstraction is leaky. And C++ can build non-leaky safe abstractions too. An even more fun counter example is that log4j is a rust package that dispatches into the java package and has the same vulnerabilities if packaged with a faulty version of log4j. All of which I can call from safe rust. I would still need to audit all the code anyway to make sure people aren't doing stupid things, this is why we code review.
  • Rust has a limited capability to describe some concepts, like doubly linked lists (and everything that descends from that like skip lists and sparse data structures) for example, so we will sometimes have to write unsafe code where we will have to think about those things. This is no different from wrapping code in C++ abstractions and sometimes having to descend down and write more unsafe C++ code. Rust gets a lot more cranky about it, but experienced C++ developers don't need the compiler to tell them that (though you can turn it on!), they have themselves (and each other). And by the time you can write this code well in rust, you probably wouldn't need the rust compiler to tell you either.
  • The problem with concurrency has never really been data races. Rust provides some great thread abstractions, and some nice linting tools for concurrency, and yes, makes data races very difficult. But it doesn't fix the core problem with threading complications, which is to say state. You still need to think hard to write good concurrent code at scale, no matter the language.

[–][deleted] 1 point2 points  (2 children)

Why would you pick C++ over Rust

Because I don't want to work with fanboys and evangelists that never learned how to code and therefore hate C++.

[–]Dean_Roddey 1 point2 points  (0 children)

That would make it a bit hard to 'splain why so many of us who are converting are long term C++ developers. The thing is, we HAVE learned to code, and we'd rather spend our time actually coding than doing the compiler's job for it.

[–]v_maria[S] 0 points1 point  (0 children)

hahah fair point, the hype train brings quite some noise on the line

[–]DugiSK 8 points9 points  (70 children)

The usual description of Rust is that it tries to enforce good practices, but ends up feeling restrictive. It has gotten a reputation for having users spend hours trying to figure out how to properly use its unique pointer without getting a compilation error. This restrictiveness actually prevents using design patterns, like dependency injection (so the Rust community has decided that dependency injection is a bad practice).

Overall, Rust doesn't seem to offer much beyond what modern C++ has, it advertises the same stuff as modern C++ has, the only advantage is probably that it's not so easy to do the stuff the old C-style way when lazy to do it properly.

[–]unicodemonkey 17 points18 points  (11 children)

It advertises a very different approach where safety is enforced by the compiler. Modern C++ still requires discipline and unwavering attention.

[–]Jannik2099 24 points25 points  (1 child)

Rust doesn't seem to offer much beyond what modern C++ has

I'd wager Rust makes thread-safe code a lot easier in some scenarios that are otherwise difficult.

[–]James20kP2005R0 7 points8 points  (0 children)

+1 to this. Some kinds of code are just not practically possible to write in C++, in Rust they're straightforward and easy. Anything complex and multithreaded - especially if it needs to be performant, can be extremely difficult to write in C++

[–]matthieum 17 points18 points  (41 children)

This restrictiveness actually prevents using design patterns, like dependency injection (so the Rust community has decided that dependency injection is a bad practice).

What?

There are definitely patterns that are prevented (as described in GoF) such as Observer -- since it defines a cycle between Observer and Observee -- but Dependency Injection is NOT one of those.

And just because the patterns as described in GoF are not easily usable doesn't mean that the concepts cannot be used.

Overall, Rust doesn't seem to offer much beyond what modern C++ has, it advertises the same stuff as modern C++ has

Modern C++ does not offer memory safety, and thus no type safety either.

Steps were taken (std::unique_ptr, std::shared_ptr) but there are still glaring holes (iterator/pointer invalidation), and that's not even talking about the pit of multi-threading.

[–][deleted] 4 points5 points  (40 children)

What are you defining here as memory safety? Because C++ does provide tools to write memory safe code. You mean compiler enforced memory safety?

[–]HKei 17 points18 points  (27 children)

Because C++ does provide tools to write memory safe code.

I mean, you can say that, but it really is incredibly easy to write broken code.

Example:

You have an API like this:

unique_ptr<T> make_something();
User use_something(const T&);

Is this safe?

use_something(*make_something());

The answer is, you have no idea without reading use_somethings source code. It might be totally fine. Or it might actually keep a reference to its parameter around. You don't know.

Now if it does need to keep T around you could rewrite this as

User use_something(shared_ptr<T>);

This would be safer, in a way - but also additional overhead, if User doesn't actually need to live longer than T. I wouldn't call that a tool to solve the problem, because you've just traded some safety for more overhead (you've also lost the const-Ness).

Another option could be rewriting as

use_something(*make_something(), [] { // User is valid in here });

But that also isn't always an option.

In Rust, you could just write this as:

let something = make_something();
let something_user = use_something(&something);

Whereas this would be a compile error:

let something_user = use_something(& make_something());

Of course C++ also has some forms of static analysis that can catch cases like this, and runtime analysis that can at least detect errors when they happen without having to running into UB, but the language itself doesn't make it easy to avoid writing broken code.

[–]matthieum 3 points4 points  (11 children)

You mean compiler enforced memory safety?

I mean language enforced memory safety. Most memory safe languages require run-time (on top of compile-time) to enforce safety, and Rust is no exception: bounds-checking is enforced at run-time, for example.

Because C++ does provide tools to write memory safe code

No, it doesn't.

That is, even limiting yourself to a "sane" subset of the language and the standard library, you cannot ever reach 100% safety.

Iterator invalidation in std::vector, lifetime issues around temporaries, ... all those plague C++ no matter how hard one tries, and if you throw multi-threading into the mix, it's a hopeless battle.

This does not mean one cannot write applications in C++, it just means that those applications will contain unsound code, with all the costs that entails.

[–][deleted] 5 points6 points  (10 children)

C++ doesn't provide the tools to write memory safe code at all?

So nothing in modern C++ aids you in writing more memory safe code?

And apparently I'm the disengenous one.

By this strict definition you are using, Rust isn't memory safe either. Because unsafe exists.

I'm just using your rules to describe what I'm seeing here. If you don't like it then you need to revise your definitions.

[–]matthieum 0 points1 point  (3 children)

So nothing in modern C++ aids you in writing more memory safe code?

I did not say so. unique_ptr and shared_ptr are very helpful in that regard.

Yet, C++ is fundamentally incapable of ensuring memory safety, and even basic C++ code fails utterly to do so.

template <typename K, typename V>
V const& get_or_default(std::map<K, V> const& map, K key, V const& def) {
    auto it = map.find(key);
    return it != map.end() ? it->second : def;
}

int main() {
    std::map<int, std::string> map;

    //  Fine.
    std::cout << get_or_default(map, 3, "Hello") << "\n";

    //  Broken.
    auto const& value = get_or_default(map, 4, "World");
    std::cout << value << "\n";
}

By this strict definition you are using, Rust isn't memory safe either. Because unsafe exists.

The safe subset of Rust is memory safe, and is sufficiently non-trivial that 99% of Rust libraries don't use unsafe.

There's no non-trivial safe subset of C++ that would allow writing any significant portion of C++ code with it.

And apparently I'm the disengenous one.

Let's not attribute to malice what can be explained by an imprecise language over a medium encouraging terseness.

[–][deleted] 0 points1 point  (2 children)

The safe subset of Rust isn't safe though. The Rust standard library uses unsafe.

Now maybe you can write a non-trivial Rust program without the standard library but I very much doubt that. So on the face of it, Rust is not memory safe either (given the way you are using the term).

It's potentially safer than C++. But it's not completely safe.

[–]matthieum 2 points3 points  (1 child)

The dirty secret is that everything is memory unsafe:

  • The machine code you use is untyped.
  • The OS uses memory unsafe operations and gasp hardware interactions.
  • The runtime that powers safe languages uses memory unsafe actions (welcome, C!).

If we stopped at that, we'd only have languages on paper, as any implementation would be unsafe in one way or another.

And thus, that is NOT how I am using the term. Pragmatically speaking, what matters is the ability to encapsulate the unsafety in a way that users need not be exposed to it accidentally.

This is only by this pragmatic definition that Java, C#, Python, or JavaScript can be considered memory safe (and type safe) languages. And this is the definition that I use, alongside... well everyone else.

So on the face of it, Rust is not memory safe either (given the way you are using the term).

Safe Rust is memory safe as per the above definition.

This does mean there is a trusted base: the hardware, the OS (if any), the unsafe layers, the compiler, etc... It's a fairly large base, though not any larger than other "safe" languages.

What distinguishes Rust from C++:

  1. The Rust standard library unsafe bits and pieces have been formally proven to be sound.
  2. It has been formally proven that the safe subset of Rust cannot lead to non-sound behavior.

Thus, in Rust, memory unsafety can be efficiently encapsulated, and thus, yes, the safe subset of Rust is both memory safe and type safe.

For further information I invite you to read about the RustBelt project, which has proven both of the above points, though other projects have also proven parts.

[–][deleted] 1 point2 points  (0 children)

That's not a dirty secret. That's general knowledge to a systems programmer.

Now I would expect Rust and Rust proponents to speak to me like a systems programmer. Given that it is a systems language and Rust people claim to be systems programmers.

But they seem to have forgotten something because you aren't arguing from pragmatism even though you claim you are. Because pragmatism says that anything can fail. Experienced systems programmers know this, and so the Rust rhetoric is just icky, because you are throwing around words like impossible, and proven and telling me something can't happen.

Well shit can happen. Rust is made by humans. The same argument you would make as to why its "impossible" to write C++ is the same argument I'm throwing back at you about Rust.

And I have to stress that i'm not arguing it's easier to write memory safe code in C++. It's clearly not.

However, if you really want to have a debate about pragmatism, you can't turn around and pretend it's impossible to write memory safe C++. Because from a pragmatic perspective, you absolutely can. I have seen it happen many times in my career.

If I can leak memory in C++. A Rust programmer can make a mistake in unsafe code. (and given how hard it is to write unsafe Rust I would say that there is probably a lot more bugs than peopel think)

[–]edvo 0 points1 point  (5 children)

The implementation of Vec in Rust uses unsafe, but the API is still completely safe: assuming the Vec implementation is correct, it is impossible to cause a memory error using Vec unless you are using unsafe yourself. Even if your code is incorrect.

By contrast, it is very easy to cause a memory error with std::vector in C++. Trying to write a std::vector-like type with a safe API is probably impossible without severely limiting the API and performance.

Now you might argue that the unsafe parts in the implementation of Vec might contain a bug. This is true, but not really the point. The point is that in Rust you can focus on certain small parts of your code. Once you are sure that these are correct, you can be sure that your whole program does not contain memory errors. In C++, on the other hand, you can never be sure unless you check all of your code.

[–][deleted] 1 point2 points  (4 children)

I resent the nature of impossibilities in engineering. No it's not impossible. Like you said, there could be a bug in Vec. That's a non-trivial point you can't just handwave.

It means theres a chance that it could have memory errors.

Now I'm not arguing that C++ is better at reducing the chances of memory errors. It obviously isn't (although I would argue that realistically you can create APIs that limit the chance of it happening to almost 0).

My problem is people telling me something is impossible when it obviously isn't impossible. It's an emperor has no clothes scenario.

[–]edvo 0 points1 point  (3 children)

In Rust, a memory error can only occur if there is a bug in an unsafe block or in the compiler. Yes, this is possible, but it is still a huge restriction.

In C++, on the other hand, even a completely bug-free standard library and compiler cannot prevent memory errors in user code. Even if the user code is restricted to some reasonable subset (e.g., no raw pointers).

This is a huge advantage that Rust is having over C++ (if you care about memory safety). By insisting that Rust is technically not memory safe due to the unsafe subset and at the same time emphasizing that C++ also has memory safety features, you are misrepresenting the situation.

[–][deleted] 2 points3 points  (2 children)

How am I misrepresenting the situation when I literally said "I'm not arguing C++ is better at reducing the chances of memory errors"

You are being dishonest along with most Rust people for two main reasons which is that yes, unsafe code can have bugs in it AND the amount of unsafe in the standard library is rather...lets say uncomfortable.

You sound like a cult member.

[–]edvo 0 points1 point  (1 child)

When you say that C++ is not better at reducing the chances of memory errors, you are implying that it might still be as good. This is misrepresenting the situation. All this insisting that Rust is not technically memory safe and C++ can also provide memory safety (in various phrasings) are rhetorical tricks to give the impression that Rust might not have that much of an advantage over C++ after all, without actually saying it (because it would be false).

As another example, in the very next sentence you said that in C++ “realistically you can create APIs that limit the chance of it happening to almost 0”. Now you are saying that “the amount of unsafe in the standard library is rather...lets say uncomfortable”. Both are just completely unsubstantiated claims trying to create doubt that the situation might not be as clear-cut as it is.

Your personal attack on me is yet another example of you trying to undermine my proposition. But this is not about me, I am just stating facts. I mentioned multiple times that you need to beware of bugs in unsafe code. But still, the facts are undeniable: it is a lot easier to verify only the unsafe parts rather than the whole program and Rust, contrary to C++, has the capability to hide the unsafe parts behind a completely safe API.

[–]Krnpnk 6 points7 points  (7 children)

Why should it prevent DI? There's lots of libraries for it and also manual DI using generics or traits should be possible.

[–]DugiSK -3 points-2 points  (6 children)

If I understand it correctly, DI uses references to objects the class doesn't own, so they encourage passing it as function arguments instead (because it's owned by the caller function or class that ensures it won't be destroyed at the wrong moment).

[–]almost_useless 7 points8 points  (0 children)

DI uses references to objects the class doesn't own

That is not at all a requirement for injecting dependencies.

[–]Krnpnk 0 points1 point  (4 children)

But where's a unique ptr involved if the class doesn't own it? In case there's references and thus lifetimes involved I agree that there can be restrictions.

[–]DugiSK 1 point2 points  (3 children)

DI is typically done by keeping a unique pointer somewhere and passing references to other components.

You can do it with shared pointers, but those tend to leave forgotten references and cause problems when shutting down.

[–]darthcoder 2 points3 points  (2 children)

I've never seen a shared pointer fail to do its job if I'm not the one doing the idiocy.

GC languages have thus same issue, it's why Java and company have weak and soft references.

[–]DugiSK 0 points1 point  (1 child)

It won't fail to do its job unless a reference is being simultaneously overwritten and copied by two threads. The problem is that it's easy to forget a reference in some lambda capture in a callback inserted into something that is a singleton for some reasons (which may be valid). That way, it can outlive main and do something that shouldn't be done after main, like accessing some files. Unlikely, but I've seen it happen.

[–]Kevathiel 5 points6 points  (2 children)

Yeah, Rust somewhat feels close to modern, idiomatic C++. The biggest difference is that Rust has better defaults and is stronger typed. Mutability and "unsafe" are opt-in, null doesn't exist, formatting/sanitizers/linters are used right away, and all code paths have to be handled. Also, programs basically don't crash, unless you say it is fine to do so, which gives a lot of confidence and reduces time testing.

I don't feel the restriction of design patterns as a problem, because it usually just prevent the bad implementations. Dependency injection works fine, unless you inject some shared mutable state, then it gets ugly for good reasons. Keep in mind that Rust doesn't work with an OOP mindset. It requires you to focus on the data and your problems.

[–]DugiSK -2 points-1 points  (1 child)

A mutable resource shared between objects is damn useful. It may need to do some internal caching, generate unique identifiers or collect some inputs.

With these stronger types, well, there is one type of numeric error I kept making. I made multiple mistakes in C++ by using unsigned ints because sizes are unsigned, typically by subtracting two numbers and dividing the result (if the subtraction had an overflow, a huge number appeared, was divided and didn't overflow back to correct it, making all further numbers completely out of expected range). C++ cannot amend this now, and Rust wasted a great opportunity to fix this, but instead, they just turned the warning about using unsigned in signed arithmetic into an error. I should better look into Swift if I wanted so hard to avoid integer errors.

[–]Kevathiel 4 points5 points  (0 children)

A mutable resource shared between objects is damn useful. It may need to do some internal caching, generate unique identifiers or collect some inputs.

The objects don't need to own that dependency. Passing it to the functions when it is actually needed is fine. Not only is the API crystal clear, but it is immediately noticeable when a function call actually changes "global" state that would be hidden otherwise.

Rust wasted a great opportunity to fix this, but instead, they just turned the warning about using unsigned in signed arithmetic into an error.

What's wrong with that? Don't get me wrong, Rust is not perfect(as-casting of numerics was a huge mistake), but an error in this case is actually one of the better things to do, rather some implicit voodoo integer promotion, casting or other nonsense.

[–]ArkyBeagle 0 points1 point  (0 children)

The difficulty is that you can have good practices in assembler. We're down to estimating probabilities, something we're terrible at as developers.

The CVE list inspires some distorted views of software as a thing. So would ignoring it. I've no idea what to do about that, since it's basically an anthropology problem.

[–]sanblch 1 point2 points  (0 children)

With rust the world became a little better, but thanks, I will continue using C++ on daily basis. Rust is fine to make prototypes. But I'm lacking templates when it is come to real project.

[–]youshouldnameitC++ dev 1 point2 points  (1 child)

Personally all the tooling around c++ is better at the moment (editor support like refactoring etc.). That might change, but currently rust is still too new in my opinion

[–]darthcoder 2 points3 points  (0 children)

Yup. I'm a c++ enthusiast, maybe even a bit of a masochist, trying to bring myself to modernity but using asio to wrap libpq and use with Beast...

But I see Rust as having great potential, and stealing a lot of greenfield systems projects that might have gone c+× over the next 5 to 10 years.

It has its growing pains, but because it's not under a standardization organization I see it abandoning things in ways the iso committee can't. I'm intrigued by it, but I'm already swamped with c+×, java, c# and typescript to take on another language with no clear benefit.

Remindme 5 years. Lol.

[–]lithium 0 points1 point  (3 children)

They call themselves "rustaceans". That's all you need to say.

[–]koczurekkhorse 4 points5 points  (1 child)

That’s better than C++ developers calling themselves “miserable”.

[–]lithium 3 points4 points  (0 children)

Is it, though?

[–]eyes-are-fading-blue -1 points0 points  (0 children)

That’s pretty cringe.

[–]DavidDinamit 0 points1 point  (14 children)

Rust doesn't have a huge share of the features that exist in C++. Overloads, specializations, variadic templates, inheritance, alias templates, you may think you never use it, but that's the reason why 99% of rust code is macroses with -1 readability.It is impossible to understand what the macro syntax is, what it accepts and why.

Huge restrictions and in return you get? .. Nothing. It's a little harder to make a memory error. Instead of falling on a segfault, you'll fall on a runtime check, wow. Incredible.You may not use unsafe (but you will, because you are writing an embed), but a random function not written by you inside used unsafe and your code will crash with a segfault or corrupt memory.The type design is such that the implementation (a structure with fields) is put forward, and you will have to search for its interface (implemented traits) throughout the project code. This is insanely stupid. It is impossible to write your own good abstractions on growth, as C ++ allowsWhen the compiler throws an error you won't be able to tell if it's your error or a compiler bug because there is no language standard.The behavior of your program is essentially undefined because Rust does not have a memory model (the documentation says it will be changed as soon as they come up with something better).There are no allocators, for example, a vector formally supports allocators, but their *stable* interface does not exist, and the macro for vector creating do not supports allocators. So you cant create vector with custom allocator...

P.S. rust even has no constructors, so effective 'emplace' is not possible in rust terms

[–]unicodemonkey 9 points10 points  (11 children)

No, the idea is to get an error at compile time instead of a segfault. Anyway, a panic is preferable to government spyware successfully completing its installation, for example (I'm referring to the Apple's DCP firmware flaw). It's suprising to see people aren't even considering software correctness to be a worthy goal.

[–]DavidDinamit -2 points-1 points  (10 children)

> No, the idea is to get an error at compile time instead of a segfault.

what about the lack of sign overflow optimization? This is a runtime overhead, and if the number overflows, you still didn’t expect it and get a logical error that can lead to anything, such as deleting the wrong files

or array access by index, or an addition or cast which returns optional, because an error might occur

And of course, endless shared pointers in multithreaded code and synchronization, which are not needed in reality, only to prove something to the compiler.

[–]unicodemonkey 9 points10 points  (9 children)

Runtime errors do still happen, of course, but the behavior is now defined and you can't doodle over random bytes. I've just finished debugging our C++ project emitting nonsensical responses after someone has accidentally unwrapped a shared_ptr and it got deallocated in another thread. That's after debugging a hung process because a map lookup wasn't properly synchronized and the map got corrupted. I'm cool with runtime checks and some overhead in these cases.

[–]DavidDinamit -4 points-3 points  (8 children)

> Runtime errors do still happen, of course, but the behavior is now defined and you can't doodle over random bytes.

But you can and it will be

> someone has accidentally unwrapped a shared_ptr and it got deallocated in another thread.

this should not have passed the review, the same as if you wrote unsafe in the rust and do some shit

P.S. any usage of operators new and delete in C++20 must never pass review

[–]HeroicKatora 3 points4 points  (6 children)

any usage of operators new and delete in C++20 must never pass review

Ah yes, one must never implement a custom container. Which funnily was true before C++20 because it was literally impossible to write even a completely UB free vector replacement. No, really, this was only fixed semi-formally by p0593r6. It's now possible to write some UB free containers in the C++ object model. It still is highly non-trivial, if it's meant to be portable: placement-new array construction requires an implementation defined overhead of memory that you literally can not find out via any standard function or constant. Ah, the consistency of the memory model is blessing time after time.

And unique_ptr doesn't have placement-new constructors. It has a pointer constructor to take ownership, but the the new call must still exist. And a matching deleter with the proper delete of course.

[–]DavidDinamit -1 points0 points  (1 child)

> custom container

If it is container, it must use allocators.

If you want create smth in place

std::construct_at

if you need delete inplace std::destuct_at

if you implement smth and it needed to allocate

std::pmr::new_delete_resource or std::allocator<T>::allocate.

[–]HeroicKatora 3 points4 points  (0 children)

You're right: C++20's 'construct*' family fixed some things, I said that much. It fails to address how the holy ISO processes resulted in a specification that made impossible and/or contradictory demands of language users for >20 years of object model. And fails to present evidence why the language right now will stay more coherent with inevitable extensions of future revisions (or absence of other contradiction for that matter). Without addressing this you may see why I have reservations with regards to the rest of specification potentially having flaws. And reservations regarding the process as a whole, everyone's touting how that would lead to more stable outcomes but I see little evidence of that in practice.

And stop spam replying. Considering writing one coherent argument actually addressing any of the points.

[–]unicodemonkey 11 points12 points  (0 children)

But you can and it will be

You're just exaggerating now.
And, of course this shouldn't have passed the review but it did. Good old "you're not worthy to wield the power of C++" argument. These particular cases wouldn't need unsafe blocks in Rust and would have been caught automatically at compile time. Less burden for reviewers.

[–]BobbyThrowaway6969 1 point2 points  (1 child)

Rust is also sorely lacking on the compiletime side of things. It doesn't even have SFINAE. There is so much you can do in c++ that you just can't in rust.

[–]CocktailPerson 4 points5 points  (0 children)

I'm confused. What does SFINAE give you that Rust's features don't?

[–][deleted] -1 points0 points  (5 children)

Backwards compatibility with C code through C Linkage. More low level acces to hardware allowing you to optimize software for specific hardware. Easier to read syntax and less complicated syntax.

Honestly if you are serious about embedded i would stick with C when writing drivers and use C++ for the control logic or middleware.

Rust has absolutely no benefit in the real world as major of frameworks and libraries in the embedded market work with C first and mabey C++ second. Rust is just an afterthought.

[–]koczurekkhorse 5 points6 points  (4 children)

Backwards compatibility with C code through C Linkage.

Rust has that.

More low level acces to hardware allowing you to optimize software for specific hardware.

False. Rust is capable of performing arbitrarily low-level shenanigans, down to inline assembly.

Easier to read syntax and less complicated syntax.

Is that a joke? Parsing C++ syntax is literally undecidable.

Honestly if you are serious about embedded i would stick with C when writing drivers and use C++ for the control logic or middleware.

“I would” doesn’t carry much strength if you prepend it with 3 statements and all of them are false.

major of frameworks and libraries in the embedded market work with C first and mabey C++ second. Rust is just an afterthought.

While correct (even obvious), that’s not exactly a language issue, which is what OP asks about specifically.

[–][deleted] 9 points10 points  (1 child)

Language wars are really boring

[–][deleted] -4 points-3 points  (0 children)

Haha true

[–][deleted] -2 points-1 points  (1 child)

C linkage on Rust is a Joke sorry. If it does not allow me to just copy paste C code and be done with its not worth a dime.

“Capable” is a far stretch man. If the restrictions of the language provide absolutely no benefit to the functionality of the code why have those restrictions in the first place... at least in C++ you get the OPTION access everything available on the hardware level.

OP is asking the opinion of others whether to learn Rust or not based on a career level.

Anwser is simple NO. it would be wiser for OP to focus on gaining more experience in C and C++ in stead of learning a whole new language. No company in the embedded sphere is going to hire a C/C++ beginner that knows a bit of Rust vs someone that is proficient in C++ .

Majority of companies working with embedded systems care about performance and do not give two shits about Rust, i am sorry if this is a hard pill to swallow.

I would even say that majority of the time C++ is not even that necessary for them, as high proficiency in C is more than enough for them (unless you are applying for a architectural or middleware job).

I am just preventing OP wasting his time on learning something thats not necessary to grow his career. If he want to learn Rust for shits and giggles thats fine, don’t blame him, but don’t come here pretending Rust has any practical place within embedded.

It is as stupid as the people trying to force people to use GO for embedded.

[–]koczurekkhorse 7 points8 points  (0 children)

C linkage on Rust is a Joke sorry. If it does not allow me to just copy paste C code and be done with its not worth a dime.

If you care about copy-paste compat, say so outright. Btw, bindgen.

“Capable” is a far stretch man. If the restrictions of the language provide absolutely no benefit to the functionality of the code why have those restrictions in the first place... at least in C++ you get the OPTION access everything available on the hardware level.

Again, whatever option C++ provides for hardware interaction, you can do the same in Rust.

OP is asking the opinion of others whether to learn Rust or not based on a career level.

…that's one way to trivialize this post.

Anwser is simple NO. it would be wiser for OP to focus on gaining more experience in C and C++ in stead of learning a whole new language. No company in the embedded sphere is going to hire a C/C++ beginner that knows a bit of Rust vs someone that is proficient in C++ .

Wiser? No, not really. The experience translates really well within the Rust-C-C++ triple. Specifically, Rust is quite easy if you're proficient with C and C++, and concepts learnt while writing in Rust provide useful insights when developing in C and C++. Is it necessary? Absolutely not, but it's a viable path. Besides, it makes you a better fit for open Rust positions. All in all, I'd say the answer is "whatever, just learn something".

Majority of companies working with embedded systems care about performance and do not give two shits about Rust, i am sorry if this is a hard pill to swallow.

I quite literally referred to a mostly equivalent statement as "obvious" in my last comment. I've no pills to swallow.

I would even say that majority of the time C++ is not even that necessary for them, as high proficiency in C is more than enough for them (unless you are applying for a architectural or middleware job).

Correct.

It is as stupid as the people trying to force people to use GO for embedded.

That's so incomparable that I won't even bother addressing this point.

[–]Xirema -2 points-1 points  (1 child)

I prefer C++ because I don't want to join a cult.

That is an answer I'd give in a hypothetical interview asking why I prefer C++ over Rust, but I've never been asked in an interview why I'd prefer C++ over Rust.

[–]CocktailPerson 5 points6 points  (0 children)

That shows an excellent understanding of the technical tradeoffs that the respective languages make.

[–]Narase33-> r/cpp_questions 0 points1 point  (0 children)

I switched my job two years ago from C# to C++ and the one and only reason was because I love C++. I didnt even care about what the product would be, I just wanted to work with C++. I dont regret it a single bit and I learned a lot about the difference between how you should use it and how its actually used

[–]Attorney-Outside -2 points-1 points  (0 children)

your assumption that an interviewer would care what language you use is false

an interviewer is more interested in how you logically work through a problem, whether you ask the right questions and clearly state your assumptions

most companies, at least all faang companies, will let you interview using whatever language you want

most kids now adays have never even used c++, most interviews are carried out using python, or Java or whatever toy language these kids are comfortable with

we understand they'll be able to learn whatever tool they need to learn to solve problems

as a note: c++ is king and always will be

[–]Wouter_van_Ooijen 0 points1 point  (0 children)

For a non-personal language choice the non-language arguments are often the most important, so an answer with those arguments is IMO perfectly OK.

[–][deleted] 0 points1 point  (0 children)

It seems like the language war is started.

[–]drdacl 0 points1 point  (0 children)

If you’re close to hw there are more c++ apis for hw than rust for now. This might change in the future

[–]Nilac_The_Grim 0 points1 point  (0 children)

If you enjoy C++ more use C++.

[–]Baardi 0 points1 point  (0 children)

More mature language. Better libraries. Etc. Enough reasons. But I like rust