C pointers are intuitive in that they are literally a variable storing an address in memory. Don't get confused between pointers and heap allocation and deallocation strategies.

@pxolqopt3597

5 ай бұрын

Thats my view as well, but I do believe that pointers are really difficult up until they click, and then they are easy

@KX36

5 ай бұрын

@@pxolqopt3597 Initially it seems redundant to have an indirection to your variable when you could just use your variable because your first pointer lesson is int a = 42; int* aPtr = &a; // do stuff in the same scope with aPtr instead of a for some unexplained reason. Then you find out about dynamic allocation needing somewhere to store the address memory was allocated and it makes sense for that, then you see the benefits of pass by reference instead of by value for large objects and realise that's actually passing a pointer too. Then it make sense.

@SomeRandomPiggo

4 ай бұрын

@@pxolqopt3597 I think its just because they're explained badly, the concept that everything in C is really just memory needs to sink in for new users

@burnttoast111

3 ай бұрын

@@pxolqopt3597 Yeah, the challenging thing is the concept, which really isn't about the coding. Once you piece it all together that variables also point to places in memory, it makes a lot of sense.

@drewgraham

3 ай бұрын

​@@burnttoast111as soon as my professor spent 10 minutes drawing a memory diagram it clicked for most of the class

The feeling I get when using C++ is that if you are really careful and write your code just right, a const here, move semantics here, etc., then you can end up with code that looks very high level (in the sense that a few lines can do a lot), but also very efficient without a lot of memory copies or pointer dereferences. But, the high level part is just an illusion, because you have to think very low level to get the high level code to work efficiently. It becomes almost a game.

@artxiom

4 ай бұрын

This. I wouldn't call it illusion though. It's just that you need a humongous amount of knowledge to do it right.

@TazioC

4 ай бұрын

@@artxiom and you'd have the same problem with any language, except most other languages don't let you do that.

@Vitorian

3 ай бұрын

You dont need move semantics. It's optional. I don't use it at all.

@1Maklak

3 ай бұрын

And if you're less careful, there are "hidden" copy constructors and stuff behind a simple statement, like A = B + C + D;

@artxiom

3 ай бұрын

@@Vitorian That's silly, almost everything is optional, but move semantics are one of the most useful concepts in C++. If you don't use it you are doing it wrong.

As someone who learned the basics of programming in C in college, pointers are really easy and intuitive.

@khatdubell

5 ай бұрын

they are

@josephlabs

5 ай бұрын

Amen

@user-hh7kt4le3q

5 ай бұрын

Yeah, the problem is when you forget to call "free" or accidentally use the freed memory, or dereference the null pointer... By itself it's not that hard, but sometimes you just forget that precisely BECAUSE it is easy(kinda like forgetting a minus sign in whilst solving a Calculus problem)

@khatdubell

5 ай бұрын

​@@user-hh7kt4le3q Those are all a solved problem in C++, and has been for a long time.

@KoltPenny

5 ай бұрын

​@@user-hh7kt4le3q Well, don't forget.

Why i think C is better than C++

@saybrowt

5 ай бұрын

I mean it just is

@tedbendixson

5 ай бұрын

Ditto. C-flavored C++ all the way

@tsyf1

5 ай бұрын

Why I think x86 ASM is better than C

@ZoraAlven

5 ай бұрын

Why I think

@leshommesdupilly

5 ай бұрын

Why I think VHDL for FPGA is better than x86 asm

Love how he just jumped through the section called ' the "unsafe" excuse '

@thebrowhodoesntlift9613

5 ай бұрын

After reading... Thank god, it was a horrible argument

@mkvalor

5 ай бұрын

​@@thebrowhodoesntlift9613 I mean, you don't expect us to just take your word for it, do you? Are you willing to take a shot at giving a synopsis for why you feel that way?

@thebrowhodoesntlift9613

5 ай бұрын

​​@@mkvalorI don't, I just gave my opinion... But, I'll expand: he's equating 'unsafe' rust to writing assembly in C++... but unsafe rust is still rust, valid rust, assembly isn't C++. The real equivalent would be assembly in Rust vs C++. Unsafe it's very much a part of the language, it's just removes some of the EXTRA guarantees that rust compiler gives you. It's much more similar to templates in C++, it's a dirty way to hack around things but it is still the language itself. The rest of the article was really good though! Anyways, I might be misrepresenting him so here is the segment from the article for you to decide: "The “unsafe” excuse Upon reading this, some pundits will throw the recurring excuse “oh but Rust has unsafe mode where you can do yada yada”, so let me preface this article with this analogy. Calling “unsafe” as an escape for Rust’s rigid system is the same as saying that C++ can do inline assembly so you can copy/paste infinite optimizations done outside the compiler infrastructure. That defeats the purpose. We are analyzing what the language can do in normal operation is, not the backdoors that it allows to open when it gives in to operational pressure."

@Andrew-jh2bn

5 ай бұрын

@@mkvalor ​ I mean, it is a pretty bad argument. Sometimes you really need to do some inline assembly (this is supported in both rust and c++). One case that comes to mind is byte comparison for cryptography purposes. Often times you _really_ need to compare bytes in a constant amount of time to avoid timing attacks and make sure the compiler doesn't optimize the code and return early on the first differing byte. If you have a need for it, why would you not use this feature? then you might say "then why don't you just use assembly?" well, c++ and rust are still _much_ safer to use than raw assembly, and containing the hand written assembly code into small pieces where needed is better than throwing your hands in the air and porting your entire project to assembly. honestly, I'll probably point to this example for people that make the similar argument against rust of "but you have to use unsafe sometimes, so just use c++".

@Resurr3ction

5 ай бұрын

@@mkvalor He says unsafe Rust == assembly in C++ which isn't remotely true. Rust has inverted defaults to C++, it is safe by default and if you want you can slide back to C++-style wild west with no safety via unsafe {}. It will still be valid Rust, which is crucial to understand, but it is your responsibility to make sure it is correct & safe as you explicitly asked the compiler not to check it (e.g. using borrow checker). But the syntax and most rules will still apply as normal with some additional rules specific to unsafe blocks. Completely orthogonal to the inline assembly which can be used in both C++ and Rust.

I lived on C++ for decades. C++ is great when you control *all* the source code. Rust excells in allowing you to use 3rd party libraries painlessly and efficently.

@TehKarmalizer

5 ай бұрын

I partially agree with that. C++ as a language is a middling experience, but dependency management is god-awful, and it accentuates the annoyances of having decentralized build systems.

@qeqsiquemechanical9041

5 ай бұрын

also rust libraries tent to have 0 documentation, or some auto-generated garbage

@lukeweston1234

5 ай бұрын

@@qeqsiquemechanical9041yes because C++ libraries are the hallmark of documentation

@Andrew-jh2bn

5 ай бұрын

@@qeqsiquemechanical9041 "rust libraries tend to have 0 documentation" you sure about that? usually rust documentation is pretty great.

@DeGuerre

5 ай бұрын

Whether or not "[Technology X] allows you to rely on code that you don't control" is an advantage... well, that's up for debate. Just ask NPM.

undefined behavior means the compiler can do whatever he wants.

@casperes0912

5 ай бұрын

they

@marwan7614

5 ай бұрын

it

@yazanal-aswad3365

5 ай бұрын

just to be more specific: "implementation-defined behaviour means that the compiler must choose and document a consistent behaviour. unspecified behaviour means that from a given set of possibilities, the compiler chooses one (or different ones within the same program). undefined behaviour means arbitrary behaviour from the compiler."

@haliszekeriyaozkok4851

5 ай бұрын

in c++ and probably in c, the "int" type doesn't have explicit memory allocation value, it can be 1 byte, 2 byte or 4 byte, that depends on compiler. So probably in his case compiler turn that numbers i8 under the hood and because in rust there is no implicit memory allocation on integers, compiler basically makes that operations with 4 byte values.

@yazanal-aswad3365

5 ай бұрын

that case with the multiplication seems more like an unspecified rather than undefined behavior situation imo

UB doesn't mean compiler WILL optimise the thing, it means it MAY do that, it may also choose NOT to do that which would yield inconsistent results, for same input on different machines which have different C++ compilers.

@TrueHolarctic

5 ай бұрын

Like Prime said, it works for the authors use case. They can check all compilers and find the one that works for their hardware. HST developers pay so much attention to the smallest parts of the trade path that they sometimes write their own routers because itll save a couple of nanoseconds. Its crazy world out there, and they Know what the compiler does because they check. There is a good talk on yt about the level of optimisations they do and its mindblowing.

@Resurr3ction

5 ай бұрын

@@TrueHolarctic Except it is not guaranteed. I work in high frequency trading too and relying on stuff like this is stupid. One day it holds and the next day compiler just deleted your code (because it's UB, it can do whatever, especially Clang is super trigger happy and deletes most UBs it detecs). So yeah, crazy optimizations are done but this is beyond crazy. It's called "undefined" for a reason.

@professornumbskull5555

5 ай бұрын

@@TrueHolarctic At that point shouldn't you just use the compiler as an intermediate and then just hand tune the assembly to perfection?

@Spartan322

5 ай бұрын

@@Resurr3ction UB tends to fall into one of two big camps, it gets optimized out in some manner, or it does something kinda like what you would expect strangely, it depends on what specific behavior you're asking of the compiler as to what it will do, and there are some manners to actually force UB optimizations, 95% of which are compiler intrinsics (like std::unreachable is implemented via compiler intrinsics and is guaranteed to trigger optimizations that either trap or remove the unreachable case)

@hwstar9416

5 ай бұрын

compiler assumes undefined behavior will never happen. So it can optimize without considering it as an edge case.

I don't think I am being arrogant when I say I am a C++ expert. I like C++, but my biggest problem with it is that it is impossible to teach, and many fairly common programming styles in C++ are basically "experts only" (if you care about safety and correctness) and completely impenetrable to junior engineers. They might very well even think they understand it fully, but it is not incredibly likely they do.

@moonasha

5 ай бұрын

I took a C++ class as a junior programmer and hated it so much. Stuck with C# instead and went on to do well. It definitely didn't appeal to me as a beginner, maybe that's just me though

@cranil

5 ай бұрын

I agree c++ is a language that you can only learn and not teach.

@cziwochel3415

5 ай бұрын

Could you give some examples of C++ expert styles?

@zeitgeist1762

5 ай бұрын

What do you mean by programming styles?

@gameacc6079

5 ай бұрын

prvalues, copy elision, SFINAE etc@@cziwochel3415

I'm very happy you covered this article. I love rust and I am building great projects with it. But I feel like the common take that rust is so superior to C++ has turned into a monocultural echo chamber. I have helped build multiplayer game backends (for published titles) in C++. The truth is that many deployed C++ projects run fine for decades with no stability or security consequences to the contrary of the popular narrative. So this is very worth stating out loud.

@appstratum9747

4 ай бұрын

"The truth is that many deployed C++ projects run fine for decades with no stability or security consequences to the contrary of the popular narrative" Until... And that's the hard truth for (to the best of my knowledge) all C and C++ code bases. I say this a Rust programmer with 45 years of C experience and almost 40 years of C++ experience. I have never seen (and nor have I ever known of) a C or C++ project that didn't have stability or security issues in all of that time. I've merely observed that these things hadn't been discovered yet. Until they were.

@sweetcornwhiskey

4 ай бұрын

@@appstratum9747 In your experience, how many of these issues were due to things that Rust fixes? I don't have the experience that you do, so I don't have a reference for the types of issues that usually pop up in large c++ code bases.

@appstratum9747

4 ай бұрын

@@sweetcornwhiskey The primary categories of issues with C++ that Rust deals with at source are virtually all related to inappropriate memory access beyond that allocated, use of memory when that memory is no longer valid for use, concurrent reading and writing of the same region of memory (by accident: race conditions) and so on. All of this is covered by the Rust language and most of these problems are eliminated before the compiler compiles successfully. Another important class of errors that Rust avoids is the failure to code to cover all the possible states of branching logic. At all points in the codebase. Null pointer issues are another category of errors that are eliminated. There is no null in Rust. In Rust you are forced to deal with the possibility of a value being invalid. In C you're not. In part because what invalid represents is very difficult for the compiler to understand. Software development practices are almost always designed to limit the negative impact of the weakest members of a team. The problem with C++ is that even on the miniscule chance that everything is defect free today, at any point in future someone on the team might break it in a serious way: by introducing a memory-related defect that hasn't been detected during testing. All C++ projects have decades of vulnerability to weaker programmers introducing critical defects similar to those already mentioned. Or corner cases that weren't expected. Rust protects against much of this. Even if the software was apparently free of vulnerabilities when it entered production C++ can have serious vulnerabilities introduced down the line. Another category of errors that Rust eliminates are those related to interchangeable datatypes. Int and char for example. Or relaxed casting from one ordinal type to another. In C++ you can get away with this with possibly very nasty surprises at some point in future when you get unexpected data. Not so with Rust. It's very strict. I wish I could spend more time answering you. But I hope I have given you at least some idea. The reason Rust is so frustrating for many at the outset is that the compiler forces you to address all the things that you would otherwise have forgotten to or didn't even consider. Whereas C++ will simply compile and you will find some of those oversights in testing. It's the ones that you don't find that become security vulnerabilities down the road. The Rust compiler is criticised for being slow. And it is. But it is doing so much more for you that nobody is going to do for you when programming in C++. It annoys you and nags you. But it won't let you build software until you deal with the issues. Rust holds developers to account for their decisions. It's obstructive in that sense. The pay off is that it's much safer. When you want to do something unsafe you're very well aware that it's unsafe.

@joshuawillis7874

3 ай бұрын

@@appstratum9747 It's insane to me that anyone thinks that C and C++ devs are all 100x devs who know EXACTLY what they're doing... Code bases are living and organic - they flex and stretch before they collapse and wind up, they are often subject to change and improvement - the speed that you get when you commit to Agile development practices or follow the "Working, Right, Fast" pattern (MVP: get it working, first pass: get it right, last pass: get it fast) ultimately comes at the cost of safety. Shift-left is a real thing, it's a MASSIVE thing, it's hard to get a job without being proficient in unit testing and a red flag when somewhere doesn't do it: Rust shifts memory errors LEFT. It's made it simple to solve these errors, and helps speed up developers to get safe code who might not be as proficient by way of teaching. C++ is NOT as good as Rust in virtually (haha, virtually...) any situation, and in Rust you can just invoke unsafe code to get C-like syntax: Rust wins, every time, to say otherwise is cope lol. Addendum: And there's nothing wrong with C. There's plenty wrong with C++, but at the end of the day, it produces results which fulfill requirements. Rust is a very natural evolution of systems programming languages: it's just better at what C and C++ do. It's just better at what C tries to achieve. It's just better when safety is a requirement, and if you have any respect for your users, then safety is a requirement.

Safety is really about correctness with regards to the indented behaviour/specification, almost all segfaults are due to a faulty proof of correctness. That’s what rust guards against, whether you accept potential malicious input or not is moot.

@theRealPermagreen

5 ай бұрын

A very good point and really the reason I like rust so much compared to C/C++. Once I get a program in rust to compile without errors or (significant) warnings, I can be almost certain that said program will work exactly as I intended (with maybe a few logic bugs and the like) because the rust compiler made sure to check that the code I was writing was correct. This means I only need to be a somewhat decent rust programmer to write good rust code, whereas I would need to be an expert C/C++ programmer to write good C/C++ code. I wish more rust enthusiasts would emphasize that correctness is what the rust compiler really helps you with and that safety is more of a happy side-effect.

@joelstienlet1641

3 ай бұрын

All input is malicious, always! Because the final user will always find a way to insert data coming from an unknown origin into the program...

C++ is probably the Pioneer of no cost abstraction, modern C++ can be ridiculously optimized due to it(if you know how to use it well). It's pretty damn amazing seeing a 6 line matmul function running that fast which it has no right to. The tooling is hard to learn and idioms are hard to follow but at the end you can write with your knowledge and compiler veryy efficient code.

@dealloc

5 ай бұрын

"if you know how to use it well" is always the argument I see thrown around. What if a language would just have these zero-cost abstractions built in where you don't have to "know how to use it well" and it just works? Sounds crazy, I know.

@anon1963

5 ай бұрын

compiler likely will do better job optimizing than you

@indiesigi7807

5 ай бұрын

@@dealloc Maybe you are just very lazy and/or not smart enough?

@TehKarmalizer

5 ай бұрын

@@dealloc no language is like that. They will all run like poo if you don’t know the pitfalls.

@MACAYCZ

5 ай бұрын

@@dealloc You are now describing C.

I left to go work in C++ because the alternative was to stay and continue coding in Matlab

@isodoubIet

5 ай бұрын

F in the chat for everyone still using matlab

@Errorcode403

Ай бұрын

@@isodoubIet F

Regarding the compiled examples Rust has different save variants for simple operators: * Is unchecked multiplication that is, as the article states, not checked in release mode But there existist: .checked_mul(rhs) .saturating_mul(rhs) .wrapping_mul(rhs) which all have different begaviour regarding the overflow With that convidered what the rust program means is that programmer wants the unchecked mul and div and thats what the compiler outputs while in c++ the compiler is following this hidden list of UB rules that you need to know to decode what the program would compile into. In my opinion Rust better reflects what the programmer expressed in the program than C++

Iterator optimization is actually done before llvm. Also struct layout optimization is happening before llvm. Finally, some vectorization stuff is prepared in MIR. Naturally, clang does neither of these things, so it often fails to vectorize obvious things.

@alexpyattaev

5 ай бұрын

To beat a dead horse: pub fn noop(x: i32) -> i32 { ((x as i64 * 2) / 2) as i32 } gets optimized into an actual noop (as we are proving that overflow can not happen). So, a correct program in Rust gets correctly optimized, and shit program in Rust gets to crash rather than UB your entire production.

Unique_ptr are free 95% of the time and usually just get compiled away (though ofc. the deconstructor will get called though that you need to call either way for your program to be correct) with that rest 5% of the time is when you provide a custom deleter (though even that overhead is basically non-existent). Additionally in some cases you need to default construct a unique_ptr and then move the object into it. In this case the default construction can have some overhead but can also be compiled away in some cases.

@freezingcicada6852

5 ай бұрын

As someone learning C++ with some C# experience. I dont like Unique_ptr, its more annoying to remember and use then just slapping * and & symbols. Sure it doesnt look as cute having Unique or ComPtrs and aligning the spacing perfectly. But for learning and do things without a team/personal. RAW all the way

@sids911

5 ай бұрын

Unique cases are only "not compiled away" in case the object it is holding is not trivially destructible you can check for if the object is non destructible using a cpp concept static assert. Even then it's mostly compiled away for most -flto cases. It's pretty awesome.

@thomassynths

5 ай бұрын

In the general case the destructor also incurs an if-not-null check for the delete call or let's delete's internal logic do that check. So pick your poison: redundant if-checks or redundant delete-calls. You are at the mercy of the SSA to get rid of these. Admittedly most programming patterns are amendable to this.

@Roman-sn3kh

5 ай бұрын

@@freezingcicada6852 unique_ptr is not replacement for & and *, it's meant to be replacement mostly for `new` and `delete` (and other for custom allocators and deallocators) if using `new Class()` and later on `delete obj` rather than just using `std::make_unique()` and letting the compiler handle later on deleting of the objects is annoying for you, then I'm not sure what to tell you. But from what you wrote, it feels more like you're using it wrongly, imo it can be especially useful while being member variable of classes, where you can just omit having to handle destruction of it in the dtor and not having "space" for leaking memory.

@TsvetanDimitrov1976

5 ай бұрын

See Chander Carruth's talk on cppcon2019 why unique_ptr is not a zero cost abstraction kzread.info/dash/bejne/pHx9zdSopLbdk8Y.html

Unique pointers are a (practically) zero cost abstraction at runtime. It's interesting that such a experienced developer can be completely oblivious to core C++ concepts like RAII.

@vladimir0rus

4 ай бұрын

Did you measure the performance cost of unique_ptr vs raw ptr?

@ciCCapROSTi

3 ай бұрын

@@vladimir0rusgo to godbolt and check the generated assembly. Most of the cases, the unique ptr is not compiled into the code because it's literally just replaces a manual delete.

@andreas1lokko

2 ай бұрын

​@@vladimir0rus Measure what? It just limits how a pointer can passed. It shouldn't generate different code from a raw pointer.

@greg77389

2 ай бұрын

@@vladimir0rus unique_ptr is just a wrapper for a raw pointer that disallows copying and has some additional functions. Do you honestly think there's a difference in performance for any compiler worth its salt? Adding functions and compile-time checks does not affect runtime performance.

@vladimir0rus

2 ай бұрын

@@greg77389 additional code always affects runtime performance, even if it is code for exception or some additional function (because L1 code cache is small). Even if it just a wrapper it might add code which will be present after optimization stage.

Errors as return values and throw: Erlang IMO has the best separation and does both. Exceptions are... for exceptional situations. Things you haven't dealt with and rarely should try. The "let it crash" idea is important to the platform. (Though that works only because of the actor concurrency model.) Errors are known failures and should be handled as such. Most languages that have exceptions use them for both and it just confuses the situation and due to not having concurrency which allows you to separate out responsibilities such that you can "let it fail."

@oserodal2702

5 ай бұрын

TBF, you can implement Exceptions in Rust using panic hooks, but, I'm too stupid/lazy to dig deeper into the topic (it's also probably unidiomatic and destroys the correctness/soundness of your code).

@sproccoli

3 ай бұрын

Erlang assumes the role of both an operating system and a programming language here, though. For long-running processes in most environments, the equivalent of erlangs 'let it crash' is programs just literally crashing and being restarted by something like systemd. Its outside of a more general purpose programming languages scope of responsibility to bother caring about this. But i do agree that using exceptions as control flow is dumb.

@trapexit

3 ай бұрын

​@@sproccoliI disagree it is outside the scope. These general purpose languages are providing concurrency features which lack good error handling making usage far more difficult than needed. They treat concurrency as a 3rd class citizen and it is really harming the space. And the language typically *must* worry about this topic because without language integration they will always be lacking. Which is why every actor model grafted onto other languages always feel incomplete and more fragile than Erlang. Concurrency will only get more important going forward and if languages really need to catch up with Erlang wrt concurrency (and error handling).

I'm a Rust newby but C++ veteran. As i understand it, unique_ptr is Box and shared_ptr is Rc/Arc. shared_ptr and weak_ptr operations are threadcsafe (but not necessarily the pointee).

@xplinux22

5 ай бұрын

That comparison sounds about right to me! I think *std::shared_ptr* in particular is probably more akin to *Arc* in Rust because, if I'm not mistaken, the internal reference count is itself atomic (please feel free to correct me).

@white-bunny

5 ай бұрын

​@@xplinux22 Actually, std::shared_ptr is more akin to Option because in C++, std::shared_ptr can be null, while Arc cannot.

@xplinux22

5 ай бұрын

@@white-bunny Right. If we want to get very deep into semantics, we have to remember that Rust references and smart pointers are not nullable unlike C++.

@spell105

3 ай бұрын

@@xplinux22 C++ references aren't nullable either.

@sproccoli

3 ай бұрын

@@spell105 but c++ references aren't smart pointers.

17:03 might be just me, but pointers were super simple when I was first learning C++ in my first year of college. The problem I had to help people with the most, was the concept of inheritance and access control. They all got the pointers thing pretty quick. I even wrote my own ref-count smart pointer classes (this was well before C++11) to use in my school projects.

@npip99

Ай бұрын

Pointers are def easy, it's just an index into the 4GB byte array we call RAM. (I say 4GB as I recommend anyone to learn systems programming in 32bit first)

@PiotrPilinko

10 күн бұрын

@@npip99 In some systems pointer was not a plain index - in real mode of x86 pointers are made of segment and offset. Also null pointer was not always equal to zero (in other systems). And pointer concept is not very hard to understand, but effective dynamic memory management is - and most of mistakes in programs are related to the memory management (memory leaks, dangling pointers and so on).

@Leonhart_93

Күн бұрын

Some applications confuse people, like void or function pointers. But since I came from higher level languages where I constantly made use of callbacks and arrays holding different data types, I understood the application right away.

The idea when the unique pointer was designed and added to the language was that compilers should generally be able to completely eliminate it at compile time so its the same as rust. But in practice it turned out, because of exception stack unrolling and translation unit boundaries that there are a lot more instances where it can not be optimized away as the committee initially intended. It has gotten better with more advanced link time optimization but you still have to check if you want to make sure it actually gets optimized away fully and in normal use it probably won't be in some scenarios.

I never had an issue using ASM. In fact it was a requirement when I went to school ASM was required before C or C++. I also was required to learn it in the military. I tend to find most the programmers I know who had to learn ASM first are better programmers by far than the one's I know who didn't.

@DoctorWhoNow01

5 ай бұрын

The main issue is not how things are taught, but that so many people get into CS for the money and not for the interest. People who like coding will learn more about it and it's concepts, people that want to make money easily will hit a roadblock

@rkidy

4 ай бұрын

I believe this is an example of survivorship bias. You’re only looking at the people who started off learning assembly and *kept going*. You are not considering the many many people who would start learning assembly get intimidated/ make minimal progress and then quit. Those programmers who started using assembly are likely naturally more talented and would have succeeded regardless of what lang the started with.

@MartyAckerman310

4 ай бұрын

@@rkidyalso looking at ppl with a 20+ years of experience since ASM was a thing back then. Kind of like saying ppl who learned to drive on stick shifts are better drivers. btw, I had classes in 6502 and 8088 ASM and I just do Python now ;)

@mmss3199

4 ай бұрын

Interesting....Allah bless you my feller. I was thinking about this. Am a ME by trade, struggling w/ employment but have a REALLY nits strong interest in coding including niche stuff...or stuff that is niche so far. I will take this as a sign from God (maybe) that I am on the right track. @@DoctorWhoNow01

@rusi6219

Күн бұрын

@@DoctorWhoNow01 the main issue with computer science majors is that most of what they should be learning as part of their degree has been shifted over to electrical engineering and computer science retained pretty much just the theoretical stuff

9:15 Though even performance cost of the bounds checks is a bit nuanced. Like when using a iterator over `Vec` these checks can be mostly compiled out.

@hwstar9416

5 ай бұрын

wdym compiled out? the vec size is not known at compile time.

@remrevo3944

5 ай бұрын

@@hwstar9416 No, but when iterating over every element you don't have to test the length every single access.

@piotrj333

5 ай бұрын

@@hwstar9416 Rust bounds checks are minimal. If you have iterator loop , you know it is safe. If known size vs known index - no need for check. If you iterate from 0 to n (n user given) in array of size X, it will do bounds checks, but if you make a line before if(n < X ), the bounds check will be done only 1 time not for every iteration. And even if you do full check, max performance penalty with special loop for bounds check is 10%. typical is 2%.

@orbital1337

5 ай бұрын

Yes but likewise if you iterate over every element in C++ with a range for loop / standard algorithms you're also not going to access invalid memory. So yes, Rust incurs no performance penalty but it also has no safety benefit. This case is the same in both languages because there is no tradeoff to make. It's the raw access case where C++ chooses performance and Rust chooses safety.

@anonymousalexander6005

5 ай бұрын

The checks incur minimal, if not statistically insignificant, performance hits. If anything, it’s code size that you should worry about. In applications where you would worry about the bounds checks, you are already doing unsafe everywhere and likely to (should) use assembly or maybe C.

Couple of notes on optimizations: 1. What if you WANT overflow semantics in multiplication? Like, what if you're trying to clear the top bit? How do you force a C++ compiler to generate appropriate code? 2. Exceptions as return value are not a 0-cost abstraction. Real exceptions can be implemented by having a static mapping of function return addresses to catch blocks. This mapping can be read when throwing. So long as an exception is not thrown, the program makes a return behave as a return. Turning every throwing return into a switch creates run-time cost in the event that no exception is thrown. Java and Swift allow exceptions to be a 0-cost abstraction by forcing you to declare which functions do or don't throw, with Swift also requiring a decoration of the call site. This means you need to know an exception is there, and you must handle it or account for it. As for "You don't know what your state is after throwing", that's what RAII is for. You should ALWAYS have a clean state when returning from anything, any way. The stack rewind is meant to guarantee that.

You can get rust (nightly) to not even produce code for the function and inline it as identity (using unsafe). Calling it "the unsafe excuse" is IMO a misunderstanding of what unsafe does. Unsafe makes it sound like you're now free to do as you want, but unsafe allows you to do only three specific things you could not do before, not throw out the entire promise of rust.

@shinobuoshino5066

4 ай бұрын

Which is a limitation that NOONE competent needs.

@john3260

Ай бұрын

@@shinobuoshino5066 Sometimes, it's better to assume everyone is incompetent.

people don't realise the ridiculous amount of details one needs to know to write proper C++, to write Ok rust you don't need to hold so many miniscule details in your mind to do so, just the ownership thing(and lifetimes that are actually difficult)

@ColinBroderickMaths

5 ай бұрын

That's simply the price you pay for having a language that is actually useful, allows you to do what you need to, and doesn't constantly get in the way. If you don't need the features of C++, feel free to use something else.

@harleyspeedthrust4013

5 ай бұрын

another skill issue. to write good c++ you have to know c++. what's the problem with that?

@giorgos-4515

5 ай бұрын

C++ is not difficult to grasp, it just has an enormous amount of details you need to know, to write it properly. Sb unironically said when teaching it don't use this, that's a design flaw

@danielsan901998

5 ай бұрын

If that is a problem then just write C, the complexity of C++ is just there for when you need it, but nobody is forcing you to use it and instead you can write proper C code that is more simple.

@njnjhjh8918

5 ай бұрын

@@ColinBroderickMaths uh, the high number of miniscule details is constantly getting in the way, that's the point

The unique pointer is free in an optimized build or your compiler is stupid, unless you do unidiomatic stuff. The problem is the destructor which tests if the pointer is null and otherwise frees the pointee. On a null pointer, ideally the check can be optimized away or would be necessary anyway. Unique pointers are zero overhead. It does things for you which you want to happen. Shared pointers have a reference count which is an obvious cost. It's honestly a complete different use case. The old C++ code base that I continue to modernize can live completely on unqize pointers, it doesnt need shared pointers anywhere. I threw so many of them in the bin.

Liked this article, especially the part where it questions the safety claim. I know I am learning Rust because it looks easier to learn than C++ today and I don’t strictly need to work with it.

I have to say I love your videos! Despite all the humor you truly look over the bias fence while not being afraid to not know all the answers. That's refreshing and inspiring in a world so full of bulshit certainties.

The guy misunderstands what security is. On any "normal" desktop, as long as user input is interpreted in any way and there is a network connection, any program such as a simple ls can be exploited to gain privilige. Also there really is no difference betwen crush bug and a security bug. Even if a crash is caused not by memory misswrite, it means the situation wasnt planned for - and that opens for it being misused.

@meneldal

Ай бұрын

The program can only be exploited to get the privilege it has itself. Like if you make a single player offline game, what does the user have to get from compromising your program? Maybe they can get around piracy locks but the user doesn't get admin access if they didn't already have it. Maybe your program can be taken over by a malicious file stupid user got from the internet and loaded, the fault is mainly on the user there. If you install a mod, you have to understand it could break your computer, especially if games allow mods that are compiled libraries and not just scripts.

Hey Prime. You mentioned about implementing a Double linked list in Rust. You can break Rust ownership model by just adding an extra pointer to it. Having an Arc that points to itself may not work. But you can make an Arc that points to itself. Bypassing the memory checks of Rust.

@skeetskeet9403

5 ай бұрын

that does not in any way "break ownership". That's just a reference cycle, possible in every language, and perfectly valid in Rust as it's a shared ownership primitive. And since you're pointing this out as if it's specific to Rust, reference cycles apply to C++'s shared_ptr in the same exact way.

@rumplstiltztinkerstein

5 ай бұрын

@@skeetskeet9403Sorry about the mistake. What I meant is that it is easy to leak memory that way. Rust's compiler will not bother us with it. So implementing the double linked list using two pointers will proceed just like any other language.

shared_ptr is essentially rust's Arc. unique_ptr is the same as Box

@basilefff

5 ай бұрын

A little correction. It is essentially Rust's Rc, std::atomic is Arc.

@mario7501

5 ай бұрын

​@@basilefffThe refcounting in Rc is not atomic, or is it? In shared_ptr it is atomic, as in Arc.

@sohn7767

5 ай бұрын

@@mario7501shared_ptr has some thread safety but it isn’t actually atomic

@steffahn

5 ай бұрын

Isn't unique_ptr more like Option, but with a lot of implicit `unsafe { x.unwrap_unchecked() }`?

@basilefff

5 ай бұрын

@@mario7501 Oh, read a little bit more on this. It seems you are correct, and I was wrong.

As an older guy, I found that understanding assembly was easier than pointers and not harder. I started programming assembly on a Commodore VIC-20 before I ever heard of pointers or C. If you understand the addressing modes in assembly then you just naturally understand pointers.

learning to code in harmony with the borrow checker in Rust and then coming back to C++ will definitely make you write better C++.

std::unique_ptr does not have runtime overhead. std::unique_ptr is essentially Rust’s Box. std::shared_ptr is reference counted like Rust’s Arc. Comparing apples to apples, C++ is essentially the same to Rust in this regard.

@khatdubell

5 ай бұрын

provided you use the default deleter.

@mina86

5 ай бұрын

@@khatdubell, unique_ptr with non-default deleter is analogous to Box where Wrapped has custom Drop.

@khatdubell

5 ай бұрын

@@mina86 I meat it’s zero overhead if you use the default deleter. I can’t imagine it is if you don’t.

@mina86

5 ай бұрын

@@khatdubell, if the custom deleter has no state than it’s also zero overhead.

@lucass8119

4 ай бұрын

@@khatdubell Actually no, even with a custom deleter on unique_ptr its free. Because its templated, there's no indirection happening at all. There's no function pointer stored or called. The function is written into the type itself and inlined. Templates can really be quite magical. This is the same reason why std::sort is significantly faster than C qsort. No function pointers, no indirection, and no jumps.

You can make linked lists in rust without unsafe, much easier and cleaner, if you enable the polonius borrow checker, which is currently experimental. It is an issue in stable rust, but hopefully not for much longer.

His arguments about memory safety not being a pressing issue seem extremely hand-wavy to me.

@KX36

5 ай бұрын

Coming from C++ POV, I concur.

@user-nw8pp1cy8q

5 ай бұрын

Well, it is not a pressing issue until they lose all their money due to some UB they missed. After that it is not important anyway because the company is no more.

@lucass8119

4 ай бұрын

Domain dependent. In video games they're not a pressing issue, for example. And the idea that because you can be memory unsafe you will be is overall a stupid point. If you wrote a high-performant game in Rust you would use unsafe a lot. So the end result is the same. If it doesn't cause very many crashes then nobody cares and we all move on. If it does then you get a bug report and fix it.

@user-nw8pp1cy8q

4 ай бұрын

@@lucass8119 >In video games they're not a pressing issue, for example. Considering that many games nowadays operate with real money, it isn't true. And even without money, it is very hard to debug bugs caused by undefined behavior. Time spent on that bugs better be spent on implementing features. Also, writing correct unsafe code in Rust is easier compared to C++ so the only reason to use C++ over Rust for videogames is the current lack of mature game engines.

@shinobuoshino5066

4 ай бұрын

@@user-nw8pp1cy8q games don't operate with real money, if they did, I could modify my game to say that I paid the company billions and have all most expensive cosmetics in the game instantly.

C++'s biggest problem is the amount of people who - last year - learned how to write C++ as one did in the early 90s. At universities.

Finally, someone brought up that "safety" is not a high priority for every project!

@jimhewes7507

5 ай бұрын

I agree. Although I've seen youtube video where Herb Sutter mentioned how the government put out a report specifically calling out C++ as a unsafe language and that it should be avoided. (Unfortunately I can't remember where that video is now.) So I guess the standards committee might still have to take safety seriously, maybe more seriously than it really should need to.

@diadetediotedio6918

3 ай бұрын

Finally? This has been the defacto standart since software development started, why do you think we have such a big mess nowadays with safety?

@john3260

Ай бұрын

@@diadetediotedio6918 Yeah, it's crazy people are complaining that safety is a high priority for most projects. In fact, safety isn't prioritised nearly enough. I hate this "move fast and break things" attitude, to be honest.

In c++ std::unique_ptr is not free(in some not trivial cases), because c++ standard says that the object that is std::move from should still be in a valid state, so when you std::move std::unique_ptr the variable that is moved from is basically a nullptr, that is why before memory is freed by the destructor of std::unique_ptr it checks the internal pointer is null, that is the only cost of using unique_ptr.

As someone who just started learning Rust, and who has no computer science background. I'm really really proud of myself for understanding 50% of what qas said in the video and in the comments. especially the comments 😂😂🎉

This is a bit of a tangential point, but I find it strange that many Rust developers put the language in the forefront as if the language is a feature Languages are tools, the end user doesn't care how it's made

@jonnyso1

4 ай бұрын

Depends on the context and who's the user. Rust is used to build a lot of tools and libraries in which the language does used has implications and the users usually care.

@diadetediotedio6918

3 ай бұрын

"many Rust developers" You started biased as this is not a "Rust thing", this is a "programming thing". Just as I saw many, many, many times C++ programmers saying C++ is the unique tool that should be used.

Totally true about the large majority of applications running with mitigations disabled. Spectre mitigated libs are not the default on MSVC and not many people change that default.

You want to know how important latency is to trading, The programs run on the processor in the Mellanox network card because the latency between CPU and NIC is too expensive.

"C++ gives you more understanding and love for what rust does" - amen.

@shinobuoshino5066

4 ай бұрын

I don't see how I can love the fact that Rust is worse language than C++ by literally removing features for no reason whatsoever.

Pointers are simply a memory location. If you don't know how memory works you won't understand pointers. The problem isn't pointers... it's not understanding computers.

@rusi6219

5 ай бұрын

Literally just dedicated shelf space...pointers do take a bit of getting used to but there is absolutely nothing difficult or complicated about them.

C++'s std::unique_ptr is free; once compiled, it decays to just T*, adding an automatic delete call when it leaves scope, and it only has move semantics, not copy, which decays to pointer assignment/exchange. If you want for force it to copy, you need to explicitly extract the underlying pointer and construct a new std::unique_ptr from it, but then you're largely negating the benefits of using it; or you can promote it into a std::shared_ptr, but that has a reference counting structure which is atomically incremented/decremented on creation/deletion. Furthermore, when creating a std::unique_ptr, you can pass in a custom deleter function, enabling you to make things such as self-closing C-style file handles.

I'm trying to get C++ repositories that use cmake and vcpkg to work together and I've literally never used Rust. I'm okay with C++ going the way of the dinosaur. I want to sleep.

C++ iterators are also zero-cost by design. They messed up with ranges somewhat in that regard, not because the abstractions have overhead, the c++20 ranges abstraction is also zero-overhead. But it prevents you from writing optimal code in a lot of cases because the nature of how the chaining works discards information about the underlying structure which makes the optimization a lot more difficult for the compiler in some cases.

@thekwoka4707

5 ай бұрын

So this might be more a matter that the "plethora of compiler options" just have made them not zero cost?

@lexer_

5 ай бұрын

@@thekwoka4707 Ah, no. It's not about compiler flags. C++ iterators are the thing almost everything uses and those are completely fine. Ranges are built on top of iterators as well. (Well, ranges build on the newer iterator concept that works with a sentinel tags but that is besides the point.) One example of a typical C++20 Ranges problem is that if you have a sized range (which means the length is known) then this sizedness gets lost as soon as you chain any kind of range operation. This size property of the range can not propagate through the chaining pipeline in C++ and that is why its almost impossible to optimize those as effectively as they can for the traditional iterator loops. I think the plan was for compilers to be able to optimize this reliably but it turned out this is not actually possible. If the compiler can inline the entire thing then it can probably optimize it down to zero cost but you simply don't know if your compiler will actually be able to do that and you have to check by hand for every single case.

There is no difference from a unique ptr and a raw initialized pointer with delete being called on destruction. You would have to do something to move a raw pointer to a different class as well.

re "array accesses are checked": *kinda* true. For example in iterators, tbey are *not*, because it's known at compile time that it's within bounds.

23:55 - "[stack overflows and segmentation faults are] literally not an issue in every codebase I have worked with." Yeah, no I can see that being the case. It's honestly not easy to cause a stack overflow unless you're doing a ton of unbounded recursion, and in the vast majority of cases, you don't need recursion at all. Segfaults are easier to happen, but not particularly common. Use existing data tried-and-true data structures, track your bounds, etc. These kinds of errors should generally be caught in testing.

Pointers absolutely are simple and intuitive. Or do you consider paper with "your jacket is in the closet" complicated? I mean, as soon as you understand that computer has a memory and it's actually stored somewhere physically, pointers are the most obvious way of working with it in every regard.

@matsmcmats

4 ай бұрын

Surely, it's a big difference to just explain the concept to someone versus when you're trying to fix a bug in a complex or badly written codebase.

I usually use C instead of C++ because the minimum runtime is big with C++ and it's a chore to port it to weird microcontrollers. In driver developer where I do use C++, we use a tiny subset of it that works out pretty well. Rust lets you do some really wild stuff to pare down the runtime support while still retaining some of the features, or explicitly disabling them to enable some compile-time errors. Such as defining your own allocator and or disabling exception handling.

@uis246

4 ай бұрын

-fno-exceptions -fno-rtti for major embedded compilers(GCC and clang)

@shinobuoshino5066

4 ай бұрын

@@uis246 nooo, you cannot just do this...

I think "trees" should be arrays where parent/child indexes can be calculated with MATH. First off this is probably faster than basically maximizing cache misses by jumping around memory, but also makes it super easy to insure minimum possible height

Rust has overflow flags which you can use to instruct it how to treat places where it is possible. Don't remember them off the top of my head but it's Rust's solution to avoiding undefined behaviour in this case, it lets the programmer decide "what do you want to do if this happens, should I give a warning or what?"

-fsanitize=address and -fsanitize=thread can catch most memory and concurrency issues in your CI, but you can’t leave them on in production since they consume too much memory and slow down your execution X times. Thus you need great test coverage to stay somewhat safe.

@rohit_ind

5 ай бұрын

Agree but it need testcase to capture error case. In rust you get as part of compiler.

Move constructors and that thing I don't think causes overhead (unique_ptr); they are just there to detect at compile time unintended uses. A unique_ptr just implements the idea of unique ownership of an object that you want to create dynamically. I'm the only one that have a copy of the pointer, and if I try to copy => compilation error (that's way the copy-constructor is deleted). But if I want to "transfer ownership" (so I'm no longer the owner, but someone else), then I can explicitely move it (that's why the move constructor is implemented). And finally, the destructor will release the dynamic memory at function scope, which is a thing you would do manually anyway because you want to release the memory sooner at some point. So a unique_ptr is just for the compiler to detect the pointer is not shared.

Regarding runtime bounds checks on array accesscin Rust: When using iterators those are optimized away with only a single check per iterator. So for 99.9% of use cases, that performance hit is unnoticeable.

Yeah I know a company that has the same c++ code running from everything from smartcards to mainframes, rust has not nearly the toolchain to support that

@jonnyso1

5 ай бұрын

yet.

@pav5000

5 ай бұрын

The gap is closing year to year

@diadetediotedio6918

3 ай бұрын

C++ had 30+ years to develop, so obviously there is a gap to close.

I asked a biologist friend and their guess is that antecessor is "the thing that filled this niche before I did"

@beowulfsleeps892

5 ай бұрын

It's possibly archaic from what I've read and 'predecessor' would be more common.

I think my knowledge of c++ has helped with me improving my mathematical and computer science fundamentals, many concepts are very similar to in the literature.

unique_ptr is only more expensive if you don't use a functor as a deleter. In that case a unique_ptr takes up memory for the function pointer when it's being deleted but the actually use of the pointer while it's alive is the same as a raw pointer.

@TRex266

5 ай бұрын

Nope,destructor still has some overhead because of non-destructive move in C++, check out the video „there are no zero cost abstractions“

@lucass8119

4 ай бұрын

@@TRex266 Trivial destructors are optimized out. I would not be surprised if unique_ptr has special optimizations to complete remove the function call on a moved-from unique_ptr.

16:00, pointers are easy to understand (it really is just an address), pointer syntax on the other hand, that needs some work......

@sciencedude22

5 ай бұрын

yes and it's especially annoying considering how simple it would be to remove the arrow syntax (->). The compiler already knows if things are pointers. It doesn't need the arrow. It could have used dot syntax for everything from the beginning!

@chainingsolid

5 ай бұрын

@@sciencedude22 This is actually what D already does.

Google giving a Portuguese definition and prime's reaction broke me

@Vitorian

5 ай бұрын

/r/suddenlycaralho

not being able to deal with C pointers is a skill issue

Oh, but there are languages that never crash! A cop out example would be anything without runtime exceptions and the has its standard library built around only total functions. So indexing into a list would be `(List, Nat) -> Option`. This is a bad answer, because you will still have to consider apparently impossible cases (like assertion violations) and do _something_ then. The most sensible choice being recording the program state so you can debug it later. An actual example would be languages that let you show to the compiler a case is impossible. So instead of indexing into a list you could use `(Vect, Fin) -> T`. This is a function that takes a list of a given length, and than a finite number - between 0 and that length. What's surprising, it is possible to statically typecheck this. That is, without knowing the concrete value of n the compiler can verify your program uses this function correctly. The big problem is such languages are niche and generally lack libraries and tooling.

@JorgetePanete

5 ай бұрын

that* has

@Lttlemoi

4 ай бұрын

I suppose functional languages come close to the hypothetical language you were talking about, only adding things like monads in the part of the program that has to interface with the outside world..

@sproccoli

3 ай бұрын

*there are languages that force you to turn runtime errors into logical errors, or give up on the program ever running

@sproccoli

3 ай бұрын

@@Lttlemoi he's not talking about a hypothetical language. dependently typed languages exist and let you do this. they just aren't very useful for writing programs. but they are still cool. My favorite language in this family is F*

You get around a lot of the overhead of shared_ptr's by passing around references to it. This prevents all the reference counting overhead required if you pass it by copy.

@ThePrimeTimeagen

5 ай бұрын

... but doesn't that defeat the purpose of a shared pointer?

@Spartan322

5 ай бұрын

@@ThePrimeTimeagen Not if you don't need the atomic counter, weak references should only be used when you absolutely need the atomic reference counter.

@isodoubIet

5 ай бұрын

@@ThePrimeTimeagen No. Sometimes, all you want is the object itself, and don't really care who owns it as long as it lives "long enough" to complete whatever operation you're doing. For example, if you pass the object to a function (and that function won't place a reference to that object into another structure, which should be the case for the vast majority of free functions). In that case, the lifetime of the shared_ptr is guaranteed to exceed whatever lifetime the callee requires, so you can just pass a reference to the shared_ptr (or, as is my preference, to the owned object itself -- I care about what the object is, not the implementation detail of how it's allocated in memory). I pass a shared_ptr by value only when it makes sense for two entities to own a given object, for example in a concurrent cache. If my cache holds shared_ptrs I get to evict items from it with complete abandon because whoever picked up stuff from the cache will get a shared_ptr which won't get deleted until they're done with it. A lot of it is also down to what is idiomatic. Rust, seems to me, uses a lot of Arc and Rc where a C++ programmer would just use values instead.

@CaptainOachkatzl

5 ай бұрын

you do the same thing in rust btw

@bryce.ferenczi

5 ай бұрын

​@@ThePrimeTimeagen Depends if its meant to be an owner of it or a thread-safe view. Shared-pointer is multi-owner, its okay to pass around raw-dog pointers as non-owning views of the data. You wouldn't write void foo(const std::shared_ptr k) { std::println("K's value is {}", *k); }, instead prefer void foo(const T*) { std::println("K's value is {}", *k); }. Because you're just taking a peek at the data, even if you were mutating it, you're not taking ownership of it. If you might need to check for nullptr, then you need to do that with the raw pointer and smart pointer either way.

Point around 9:22. That is mostly false in article. There is bounds checking but not always. Do iterator loop? No bounds check. If compiler knows your index can go max to 100 index and statically you made something size of 100.. no bounds check. If you have user inputted index to check up to that number in array - yes it will do bounds check but if you do something like if (user_input< array.size() ) (basically like you would do in C) the bounds checks will be removed on array and you will do check only once instead on every iteration on loop. Even if you do full bounds check on every iteration of loop, highest performance drop i ever saw in benchmark was 10%, mostly it is 2%. Literally compiler knowing more about types from Rust and being allowed to do more agressive optimalizations sometimes easly can overtake that.

@skeetskeet9403

5 ай бұрын

The fact that the author has provided no code examples repro cases or benchmarks for their performance claims just shows to me that they are using the ancient technique of just making stuff up.

2:04 shared pointers cost something, they are pretty much the same as Rust's Arc unique pointers are MOSTLY free, not completely because it will do the freeing/deletion of the thing it points to in a function call (although I guess Link Time optimizations could theoretically inline this, but as it turns by the testing Facebook did, this does not in fact happen, so they have a small cost)

@Lttlemoi

4 ай бұрын

The freeing/deletion is required to not have memory leaks everywhere. Any decent compiler will inline the function calls no problem.

@kuhluhOG

4 ай бұрын

@@Lttlemoi yes, but you have the Destructor function call of the unique_ptr, the Destructor function call of whatever its pointing to and the freeing if you do it manually you only have the Destructor function call of the data and the freeing

if you use std::make_shared you don't get a slow-down: when accessing the pointed object via -> or *(dereference) since the control block where these atomics live and the pointer to the actually allocated resource is found, all of them are allocated very closely in memory and when accessing the pointed object on modern processors you already have the pointer to the actual resource in the cache of the processor which would make it as fast as accessing a raw pointer, only shared_ptrs have 2 counters a strong and a weak atomic counter(unique_ptr have no atomic counters since it would make no sense given the way its designed) the real cost is when you copy shared_ptrs and when they get destroyed when the increment and decrementing of the atomics occurs regarding the cost of shared_ptrs the benefit outweighs the cost when properly used

Worth mentioning that in rust if you're using Iterators you mostly shouldn't have bound checks

What that other guy basically is saying, that C++ is better because it does rely on undefined behavior to a greater extent than Rust (or to be more exact: the language implementors like CLang and GCC are optimizing more aggressively than it could be done in Rust bc of UB). That cannot be a good thing! I've seen examples, where GCC cares about signed integer overflow when in debug and "optimizes" that away whn in -O3. You don't want to have such an erratic behavior!

@joestevenson5568

4 ай бұрын

No you haven't. You've seen cases where the bug you introduced via producing UB wasn't made apparent prior to the compiler actually doing its optimisations (which are based on the assumption that you have not written a program that will allow UB to occur). This is not erratic - its entirely predictable that UB bugs are often only apparent after full optinisation.

@27:55 in that case you can use std::expected. it comes free of charge with c++23. and before that you could do it with std::optional and the like. And honstly, c++ doesn't suck. I love it. What sucks is C/C++, or reading a book or getting a course from someone who did 40 years of C development before switching to c++ and then tries to teach you c code, and then c++ after that and you end up with a horrible mess. if you do manual memory allocation or use pointer arithmetic (including c style arrays), you're most likely doing it wrong.

C pointers: to me, the statement about pointers is really true. And I think for the whole "grew up with a C64 generation", too. The first "language" I learned on the PC was assembly. Because I came from the C64, and there assembly is a must to achieve anything fast like gfx, "real" games, demos, etc. I used masm on MS-DOs (and later on windows, too). It felt like a high-level language to me, because there were multiply, loop and even string opcodes. Wow! Working with specific addresses was essential on the C64, also indirect addressing. So the concept of a pointer was very intuitive to me. int x. x is the "label" of the memory and represents the value in memory, &x is the address value of the memory, int *px is a pointer variable that stores the address to the memory, *px is the content of the memory there. Very intuitive, also the star is imho the best character to use for this arrow ;) I also saw plain C as a higher level writing system of assembly, that you can write faster and understand faster when reading. Then came #includes, std libs, and so on later for me.

2:30 The cost is there because you would still need to free the memory regardless of whether you use an unique_ptr. Don't you need to free the memory in rust as well?

@tiranito2834

5 ай бұрын

In Rust, leaking is considered safe, so I guess they don't even factor freeing into the cost. What a safe language. Typical 0 cost abstraction. Now that I took my jab at Rust, let me try to reply with something that is actually serious: I think what they are talking about is the fact that the borrow checker is something done by the compiler but not something done during runtime. In the case of cpp smart pointers, some of their variants do perform runtime checks. This argument is kind of braindead tho because Rust still has to perform runtime checks for pointers and array bounds, but I guess that the Crab sect took saint NoBoilerplate's words too literally and they really do think that Rust is "just magic".

@Spartan322

5 ай бұрын

@@tiranito2834 Doesn't help that move semantics pretty much replicate that behavior in a way that is easier to track and intuitively understand, obviously with the cost of it being less safe, which honestly I'm totally fine with the theoretical lack of safety because it kinda requires deliberate action to cause such problems, and C++ is actually pretty good with move semantics, the annoying thing is duplication of code to write out move semantics for your classes.

@indiesigi7807

5 ай бұрын

@@Spartan322 Just command chatgpt to do it. I'm not writing that boilerplate myself nowadays.

@isodoubIet

5 ай бұрын

@@tiranito2834 " leaking is considered safe" That goalpost move is so BS though seriously. "We can't solve the problem so we define it as non-existent".

@skeetskeet9403

5 ай бұрын

​​​​@@isodoubIetwell, not really. leaking memory is considered safe because leaking memory on a fundamental level can be a desirable thing! For example, if you have a resource that you know will exist until the program exits. And memory leaks are fundamentally impossible to solve, you can always have a global value, or just put a thread with the value into an infinite loop. The reason it's not a problem in Rust is because the only times it happens are: you called Box::leak, explicitly leaking a value you called std::mem::forget, explicitly avoiding running the destructor of the value you have created a reference-counted cycle(which is a problem fundamental to reference counting as a shared ownership system, and exists in the same way in C++ with shared_ptr)

Some comments on the rust-generated assembly for the int overflow/underflow example nop: leal (%rdi, %rdi), %eax Sarl %eax retq First off; Mildly confusing the assembly for the C++ and Rust do not use the same style where the result register is the left in C++ and the right in Rust, but that aside, some fun things happen here. The use of the leal instruction is pretty clever. It compacts things a bit, though I'm not convinced its necessarily faster than the fatter version add rdi, rdi mov eax, rdi (style of the C++ listed assembly) By using the load effective address (lea) instruction we get both the move of di into ax and the mul(2) in one instruction. Lea would also allow for doing something like (value*4+4) all in one instruction. I always thought it interesting the lea instruction became a math instruction as it is named and intended more as a memory instruction but because it can operate on pointers in this way we can just pretend any number is a pointer and get faster math by utilising it. I also want to note that I find it interesting rusts here uses the 64-bit registers rdi instead of their 32-bit counterparts, edi. Maybe there are some limitations in lea requiring it, as it is truncated back to 32-bits in eax, or maybe it's simply faster or something. But interesting nonetheless.

@casperes0912

5 ай бұрын

@@anon_y_mousse the ADD I talked about was not in relation to c++. Just an ekspansion of the lea. Wrt. Syntax the author could’ve normalised it. But no biggie

@TsvetanDimitrov1976

5 ай бұрын

The main difference is that leal (%rdi, %rdi), %eax doesn't touch the flags, while add does.

using pointers on a PIC micro controller was something that helped pointers click all that much more

Henrique wrote the article and antecessor is a common word in spanish speaking places for 'predecessor'.

My fast take on Rust vs C++. They are stairs that goes to thousand steps into the sky. Rust's staircase has firm and strong handrails and also provide you with a harness, whereas C++ it might have handrails, but you have no harness. How much can you trust yourself to not f- it up, and fall, and if you're in a team, everyone tied together, how much can you trust everyone from not falling?

@scotthinton4610

5 ай бұрын

Maybe the team aspect of your question is what's really important here. Folks programming in C++ might be writing < 1 memory/concurrency bug / X LoC, but what if the compiler could bring everyone to that level or 0 bugs at all, even if it's sometimes annoying to "fight" it? Frankly I'd prefer the latter even if I *think* I have reasonable competency to produce code that does not have memory/concurrency bugs in C++ (at least not by the time I've identified and fixed them with tests).

15:17, ancestor is someone long passed away, no longer alive. Antecessor is someone previous in line, like queued or something, still alive.

@Vitorian

5 ай бұрын

@@anon_y_mousse Overqualified for life 🤣

23:47, after Sanitizers, there's no much room for loosing too much time catching a memory bug. Plus, they allow us to be more productive, coding faster, getting seg faults often, fixing them right away.

Unique pointer is basically just a typesafe RAII move-only pointer with an optional custom deleter.

20:00 That's not even a positive though... If you have worked on windows, you know that MSVC shouts at you if you use scanf and forces you to use scanf_s instead, however the scanf_s doesn't exist on the GCC and many other distributions. It happens because while scanf_s isn't an ISO standard C++ function, Microsoft can basically do what it wants with MSVC, and get away with it.

@citer5574

5 ай бұрын

GCC is full of shit that isn't in the ISO standard

@assyyn4139

5 ай бұрын

It's a compiler extension, you can turn it off.

@sids911

5 ай бұрын

I mean it is out of standards. why use it? Nothing outside the standard is guaranteed by C++ compilers. I haven't used scanf in ages lol.

@VojtaJavora

5 ай бұрын

​@@sids911compiler can guarantee whatever they want

@professornumbskull5555

5 ай бұрын

@@sids911 It's not about out of standards or inside standards. The thing is, it is part of one compiler but not of other and is allowed. It can happen for other things and does happen.

With regards to exceptions; we never use in our game engine. It always results in slower code. And since recovering from an exception can notoriously hard anyway, there is not really a reason to keep them in there at such cost. We just use asserts all the time, that will be present in debug and test mode and will be dead stripped completely in production. Asserts will cause a debug breakpoint when attached to a debugger and/or a debug screen showing assert information which can be passed on to the dev team. Also like the author is stating as well, typically we almost never have out of bounds bugs anymore. Experience really does help here. So I don’t see the added value of that extra safety either, especially at that cost: you will have to use unsafe Rust, which is complex and kind of defeating the whole point of using Rust. Or you have to fight the borrow checker and accept that the resulting code is less optimal. Memory leaks etc, can also be caused by resources being held by other systems, or not being freed in time. Switching between two levels for instance, is always tricky. This is a design problem and not something Rust can solve.

@sids911

5 ай бұрын

Have you tested out C++ expected... In my testing is has god awful performance compared to asserts and even exception but I would like to know your thoughts.

@shinobuoshino5066

4 ай бұрын

You're clearly a terrible programmer because performance doesn't mean shit when exception is std::bad_alloc and you only need to dump crash report and tell user that they should stop being poor, 2GB RAM isn't enough in 2024.

@joestevenson5568

4 ай бұрын

You're simply wrong? Exceptions produce faster executing code than return error types.

Using rust because safety and borrow checker ❌️ Using rust because hating on cmake and others C/C++ build system ✅️

Having multiple layers of IR isn't just a Rust thing. GCC's compilation pipeline for C and C++ involves a "GENERIC" IR that, as I understand it, is equivalent to LLVM IR, and then a more internal IR named GIMPLE which is processed in three distinct stages (High-level GIMPLE, Low-level GIMPLE, and SSA GIMPLE).

Where Rust really shines is once you start working on a project of significant size (and especially if you're working with a team of developers). Sure, if you're writing a smaller program, it's easy to globally reason about how your entire program uses its memory. Heck, it's not that hard for a moderately experienced C developer to create a small bug-free program on their first try. But once your program starts getting into the tens of thousands, hundreds of thousands, or even millions of lines of code, it's practically impossible for one person to keep the memory flow in their head. The fact that Rust allows you to prove at compile-time that all of your functions, structs, and modules cannot be misused by others (or your future self) is a godsend. Sure C++ also has some level of abstraction capabilities, but it's not even close to being as foolproof as Rust. If it was there wouldn't have been a need to create Rust in the first place. (Also a small nitpick, I really like not needing to have separate header and source files :) )

@shinobuoshino5066

4 ай бұрын

wake me up when your program is millions of lines of code

@Lttlemoi

4 ай бұрын

I'm sorry you have to work with such substandard coders that a "small bug-free program on their first try" seems like a milestone to you.

@joestevenson5568

4 ай бұрын

How many Rust projects have millions of lines of code? How can you be so sure its excellent at this use case when there are so few examples of it being done?

Idk, I was using rust for a while and thought I liked it over cpp, but then I realized I was wrong as I got more and more frustrated with how it wasn’t meeting my performance expectations and how much friction it felt like there was with the compiler when writing it

@Acalamity

4 ай бұрын

Exactly my experience. Switched to C++ after 4 years of Rust.

@jumpman120

4 ай бұрын

@KayOScode I am sure you work at Nasa and you search ultimate frontier or real time operating system which can kill people if error happens... Like Airbus embedded system ? No kidding you are produce useless programs in a giant entreprise which produce useless programs ....

@plaidchuck

4 ай бұрын

@@jumpman120k well newsflash bud NASA isnt the only place programmers work.

@Leonhart_93

Күн бұрын

Yep, this is the reason why the adoption stagnates even though there is this incredible push by a small community. They never mention actual downsides, they either hide them or they have no idea.

Like others have said, dude's right about c pointers. It's a variable that stores a memory address. That's pretty damn simple.

How tf are pointers difficult? Is this easy and intuitive for me because C++ was my first "real" programming language? Heck, C++ makes it MORE clear by explicitly distinguishing between values, pointers, and references, as opposed to Java where a variable is a value or a reference depending on its type.

I don't think it's fair to say all array accesses are checked at runtime. If you use an iterator, they aren't, at least that's my understanding. If you're writing an algorithm that will make random access, has hot path perf requirements and can know it's safe to subscript, use the _unchecked variant, easy. I don't get why everyone assumes that experts should not use unsafe{} in any circumstance. If they'd otherwise use C++ to get the same perf, it's still strictly better to annotate that behavior and get memory safety by default in 90% of your code.

@Spartan322

5 ай бұрын

I can't think of a case where using modern C++ has ever resulted in losing memory safety that wouldn't have needed to be lost in Rust anyway. Every time I've ever run into this its specifically because I used C over relying on C++.

@diadetediotedio6918

3 ай бұрын

@@Spartan322 Gladly, the world is larger than your imagination.

@Spartan322

3 ай бұрын

@@diadetediotedio6918 Memory safety is trivial in C++, if you use RAII for memory, especially with smart pointers and containers, you won't run into memory safety issues, if you use the C++17 and C++20 type-erasure types like optional, any, and variant, and if you include ref_wrapper, you can do pretty much everything without needing to deal with memory at all.

The age of microservices should favor C++. The toughest challenges come from working on large C++ projects. The same goes for C.

@araarathisyomama787

5 ай бұрын

Do you have an opinion on which one of those scales better with increasing project size?

@Bozebo

5 ай бұрын

I'm not sure but wouldn't there already such an overhead in latency that you might as well just use a higher level, safe, simple language? But maybe you could orchestrate at the process level, not containers, but then we're just going back closer to metal anyway and the micorservice is just the smaller scaling unit conceptually.

@banatibor83

5 ай бұрын

C++ do not brings any benefit. Extremely hard to learn and use it well. Then your super fast microservice is packaged into a docker image, uploaded into kubernetes where it runs in a pod.

@JuMi896

5 ай бұрын

Acording to jetbrains survey from 2021, 8% of people who work on microservices use C++ and C. Most of them use java, javascript, python. Can you trust this survey? Duno

The article is not bad, but I had to chuckle when the author wrote segmentation faults are not an issue in C++. I once tried to integrate DJI's own lib to extract thermal information from drone pictures and got a crash within 5 minutes, because their SDK developers allocated something with "new" and tried to deallocate the same thing with "free()". Pretty much every single time I try to integrate a third party solution to any of our business apps I can find glaring memory issues right away. We even had obscure cases of libcurl crashing on us in the past. So yeah, big disagree.

Sometimes in Rust iterators are negative cost abstractions. They can produce faster code than the equivalent plain loop.

Unique pointer is the same as Box in rust.

I still am a c++ programmer 😊

@simon2509

5 ай бұрын

pointers are pretty simple. object orientation, monads, etc, are hard but pointers? im not sure ive heard someone have a question about pointers without also being confused while their implementation isnt working.

They did get the Arrays thing wrong. Arrays in Rust are not bounds checked when accessed. Vectors are, but Vector Slices are not (presumably the slice itself checks when it is created, so you can reuse a slice to have that check happen once). IDK how hte Rust structs parallel the C++ stuff, but anything in Rust where you can 100% know the size of should just be an Array, and now you don't have that hit. Anything you don't know, in C++ would be a gamble.

@gnikdroy

4 ай бұрын

No. Bound checking does happen. It will get optimized away if the compiler can infer all indexes are valid. But if you get the index from a server or user input, that optimization can never happen. If rust didn't perform mandatory bounds checking, it too would fall victim of the SegFaults

Try to write rust for GPUs and find out where C++ shines.

@Vitorian

5 ай бұрын

Great point

@apathypower9559

5 ай бұрын

You should check out Asahi's M2 graphics driver written in Rust. She said that Rust greatly improved the ease and speed of development of the project compared to C (that might not be her exact words, but it's the essential idea).

@mfc1190

5 ай бұрын

@@apathypower9559 thanks for the rec, I’ll check it out!

@Vitorian

4 ай бұрын

@@apathypower9559 Just the fact that the Rust community is now widely accepting the use of unsafe sections everywhere, which was unacceptable just 5 years ago, it is very telling.