Rust absolutely took RAII, smart pointers, zero overhead abstractions from C++. However I would argue that Rust's generics are more likely been inspired by ML languages like Ocaml and Haskell. I might be wrong about this so please correct me if Im wrong.
@vytah I think at least with Haskle it's a dyn so there is runtime type information. Because for things like structs it's defined as an interface. Like you don't need to concern urself with whether something is dyn or not But with rust you get the C++ style compile the whole dam function from scratch for that type.
I wish you hadn't blurred your section titles at the beginning. I get that it's good for the algorithm to keep people watching, but it doesn't feel like it's optimized for teaching. > Rust only allows you to allocate resources using RAII constructs. There are raw alloc/dealloc functions; they're just unsafe. > Rust has made generic programming more accessible and safer, while maintaining its power... There are important things that you can do with C++ templates but not with Rust generics. Templates offer "compile-time duck typing", which is why they're so flexible but also why their compiler errors are noisy. Rust doesn't (yet?) have specialization, and its const features are more limited. Maybe this is nitpicking of me, but your channel is prominent on TH-cam, and I think it's important for prominent Rust advocates to get these little details right. Experienced C++ folks tend to pick up on this stuff, and it makes them feel like they can't trust Rust folks to talk about tradeoffs fairly.
Yeah, I had issues with these points too. That said, I forgive him because RAII was mentioned _and I love RAII_ . When learning Rust (while already being familiar with C++) I have came to terms with that generics are a really focused tool, and while they are not insanely powerful like templates, they work quite well when taken in context of the entire language (or maybe more precisely, type system). That said, I am not on the level of some C++ users that can do _anything_ with some templates that are unreadable to anyone but others of their kind lol.
Well, you can't trust Rustaceans to speak even-handedly. If it's not lying by omission, it's outright propaganda via slurs against better languages. For instance, the crack about better syntax is patently false as the irregular syntax of Rust makes it harder to read and it's noisier in either case.
@@Tempestissiman Compared to the majority of Rustaceans who only know Rust and maybe one other language which they switched from after 6 months or less. Even those supposed C++ converts who only ever used C++ as C with classes I would say don't know what they're talking about.
There are multiple methods to have a stable ABI in Rust. One of the core issues with C-ABI is how terrifyingly un-defined/compiler dependent you actually are. If you want an ABI right now in Rust, *you* have to define what you *mean* by an ABI. This is true for "true ABI-stable" libraries elsewhere (glibc for ex.) which have to do a lot of soname magic to custom define all the compatibilities. So, for the easy path: "just compile the world and cargo/rust do the internal ABI" but if you want an actual ABI to expose externally, define it! There are a few different options depending on what you want out of your ABI-API specifically because there are levels of how much you actually *care* about ABI. Work is also ongoing on a syslinker-aware ABI called "crABI". For other levels of ABI stability: * Rust Crate abi_stable: "For Rust-to-Rust ffi, with a focus on creating libraries loaded at program startup, and with load-time type-checking." * Rust Crate stabby: "stabby is your one-stop-shop to create stable external binary interfaces for your shared libraries easily, without having your sum-types (enums) explode in size. * The Extism ecosystem: If you are looking more for plugins/modules to a mian-app type thing * more besides for more niche uses (such as "USB device firmware protocol packets" and more!)
Ironically, C++ just got a large proposal called Safe C++. It includes safety-by-default and the unsafe keyword, borrows and lifetimes, MIR and a borrow checker, destructive moves and relocatable types, send/sync traits, and more. If it passes, soon C++ will have stolen Rust's best features right back!
@@HermanWillems Sort of? Variables are still mutable by default, but when you call methods or pass them as parameters they are immutable unless you use explicit syntax to make a mutable reference or borrow.
@@lucascamelo3079 I just read the proposal and it's big copium lmao. They put as many Rust features as they wanted in their "safety mode". If C++ devs want to make their language look like Rust why not use Rust 🤣
Why is every video on Rust the exact same? Every Rust content creator seems to just re-hash the same three talking points over, and over, and over, and over again. Like, I could already guess two of the three points within three seconds of reading the title.
A HUGE thing that Rust is missing is dynamic linking of libraries and stable ABI. Everything compiles to a huge binary, which is ok (and even desirable) for big apps but much less so for small tools and helpers.
Of course you can use dynamic linking. It's very useful for fast debug builds in large projects. The problem is that it's not recommended to use dlls compiled on different compiler versions (the ABI thing), meaning you probably need one party to compile every rust app (such as a distro). Rust projects are also famously lazy, leading to many tiny and outdated libraries, that cause version conflicts for distros. Static linking has some security and performance advantages, is not as large as you think due to dead code analysis, and is the standard. Maybe there should be a push for everyone to either update their crates or somehow mark them as inseparable.
@@CjqNslXUcM If you want to dynamically link something, that implies a lot of boilerplate, unsafe code and is a decently-size PITA overall - feel free to correct me if I'm wrong though. Not sure how panic unwinding works in that case either. Static linking is nice but for small system tools-wide like those of GNU, dynamic linking is the only reasonable way as there will be thousands of them.
Rust does have dynamic linking, in fact you can even dynamically link using the C ABI. The current limitation is that Rust doesn't provide its own stable ABI for dynamically linking higher level abstractions. Finally, there is an unofficial stable ABI provided by Stabby (Stable ABI) that's just a simple dependency you can include in your project if you want it.
Sadly one of the things Rust still hasn't stolen from C++ is its capability for Compiletime-Programming. Rust's const still feels like C++14 constexpr which is well 10 years old. Really hope to see Rust improve in that regard.
70% of bugs are memory safety issues because of c++ or becaue of ugliness windows C API where struct names are sequence of random characters someone has written by smashing keyboard by hand ?
I presume you are referring to "Hungarian Notation" where the datatype of the variable is encoded into the name. This certainly is an ugly standard, and now that we have PLS there is no more need for it, but Microsoft loves their "forever" backward compatability (nevermind that it doesn't actually work) and so will likely never change.
So now Microsoft is trustworthy? After decades of being untrustworthy and dishonest. And let's not forget that Microsoft has milked c++ into oblivion from late 80's. So it's c++ fault not Microsoft engineers who used? Such an extreme example of hypocrisy. Is rust gonna magically make stupid people smart? I don't think so.
This was a nice video, I like Rust, I'm glad it exists and I'll try to learn some in the future. To be honest the only reason I haven't tried learning it so far is because the code just looks ugly to me. I admit the generics look cleaner though. Also the argument at 5:00 doesn't seem valid to me, any good C++ programmer would tell you not checking the return value of a non [[nodiscard]] function is a bug in itself. Had you just checked to make sure the iterator was valid to dereference, it would have been the equivalent to Rust's match case. It seems like you intentionally wrote two different pieces of code to do two different things, and then tried to compare them as if they did the same thing?
@@31redorange08 And yet there's nothing to stop a good programmer from always checking it regardless. There's also nothing to stop an individual compiler vendor from checking it by default, nor is there anything to stop programmers from using the existing tooling for both C and C++ to check it outside of the compiler. Write a makefile template and copy it for every new project and you won't have to remember any individual steps in setting up checks.
C++ template syntax with concepts or auto deduction is actually more readable than Rusts edition... As far as I'm concerned this Rust video was already outdated even before it came out.
@@RustIsWinning This is a C++ template function: void hoho( auto x ) And this: void hoho( std::integral auto x ) At least learn the latest standards of languages before spitting on them... And yes, I've used Rust and my verdict was that it's a promising educational project that is far too over hyped and is thereby causing much more damage than it does good. (exhibit a: you) Rust to programming is like crypto to banking: the best thing that it gives is a kick in the but to complacent old timers to evolve and that's about it. It has some good ideas but in the end it's just another toy one trick pony that preferred to go down the revolution path instead of evolution of others for the short term gain of few and long term loss of many. And yes, C++ template meta programming (which you're probably referring to as you probably don't know that there is a difference between templates, concepts and template meta programming...) can get convoluted really fast but even that is only one of the tools in the toolbox which shouldn't be overused but is is great when really needed.
Rust has manual free types but its all in unsafe. The main thing rust does with RAII that C++ is not the restriction but rather the checking In C++ when u want to pass refrences u do a .get() or even give a refrence. But nothing actually checks ag9nst uae after free here. RAII actually makes it easier to do use after free when passing pointers
Rust is great for writing self-contained applications. The lack of a way to expose functionality to C limits it for writing libraries. That's a shame, because this is what prevents us rewriting core Linux libraries and makes it harder for Linux kernel development.
You make great points, and it also prevents us from gaining community experience living with and maintaining production Rust codebases. That lack of battle tested systems level projects, is why there is opposition to Rust adoption in existing codebases.
@@cyberpunkspike That and just general hate for Rust for some reason. Even many previous proponents of Rust have basically turned against it. Not that's because it's not novel enough to be "cool" any more, or because of the foundation drama, but looking at (for instance) the Primagens views on Rust now vs 2 years ago is pretty much a complete 180.
It IS possible to expose functionality to C from Rust. So I don't get what the problem is. If you expect painless interaction between two different programming languages, that is impossible for many reasons. You will always need to write glue code to massage around the differences in platforms. If only to wrap C enums into Rust enums, or C strings into Rust strings. Libraries exist to help with this. One problem is the persistent love for huge, monolithic programs that do everything. Monoliths are very hard to refactor to a different programming language. That is one reason why it is usually better to split large programs into several, smaller programs. Specifically for the Linux kernel, I think it is definitely useful to implement large & complex beasts like an USB stack, TCP/IP stack, file system or display driver in Rust, but not simple stuff. The overhead of moving between the two abstractions (C and Rust) will become a burden if e.g.part of the task switching code is in Rust and another in C. That just doesn't make sense. Neither does it make sense to write part of the ext4 file system in C and the rest in Rust. Sadly, for those projects, you have to move to another language in one go, all-or-nothing. To try and migrate file-by-file is simply not possible, and that is not Rust's fault. The idea that you could do that is totally unrealistic.
Funny you mention templates and generics because to me thats one of the weakest parts of Rust. "Generic specialization" Rust has been working on it since 2014(still in nightly). Rust's generic/traits/async/const features do not work well together. Everything that makes using more than one feature at a time less painful is in a crate or in nightly. What color is your runtime? what color is your function?
Everyone seems to want programmers languages to have no flaws or shortcomings, and if they do have a flaw they deem sufficiently important, then the whole language is garbage. A childish attitude imo. I’m not saying it necessarily applies in your case, but it’s an impression I get from many of the comments here and elsewhere.
I think one big issue holding compatibility with other languages back is the lack of a defined abi. Not having an abi prevents other languages to support rust as a direct and efficient ffi target. For example I am currently designing a language similar to rust but with some personal changes. I would like to support many languages as native abi targets allowing for seamless integration and mixing of code written in the different languages. With a defined abi even direct inline mix and match code would be possible. As my language is similar to rust and holds many of the same guarantees even safe to safe function interaction would work.
You must be the third person saying this. It is complete nonsense. Even C++ doesn't have a stable ABI, in spite of efforts by e.g. M$ to push theirs through. Ever since Fortran, ALL compiled programming languages have supported the Fortran ABI for calling functions in other link units. Trying to define ABI's for other languages are always attempts at vendor lock-in, because it means you can only use the generated link units from their compiler platform. The moment a more advanced ABI is adopted as standard is the moment that C (and Fortran) become unusable. That day is still a long way off. Also, ABI's stifle innovation, because when a language gets a new feature, it usually means the ABI must change to accommodate it. That some compiler vendors for C++ have frozen their ABI's means C++ is truly a mature language with only syntactical innovation. It is good to have a stable ABI so library vendors can ship closed-source, pre-compiled code. But the Fortran ABI fulfills that role marvelously. It has done that for 60 years, and will probably continue to do so for another 60.
@@TheEvertw the thing with the c abi is that it's quite limited. It only defines a handful of things to work with. The biggest downside is that it doesn't support lifetimes and generics. This means that there is currently no abi that qualifies to rusts safety guarantees meaning that any ffi needs to be considered unsafe. Even when the other languages defines the same rules. The 2 cannot communicate the lifetime relationship. The second thing are generics which have the same problem with lack of communication. There is no abi that allows compilers to communicate which generic specialization the other needs. Sure a fixed abi makes innovation more difficult but correct me when I'm wrong but didn't rust solve abi incompatibility with itself using the Edition system where you can combine projects of different rust versions and abis without updating source code.
@@redcrafterlppa303 True, and the same holds for other programming languages. If you want other code to interact with your code, you will need to use the lowest common denominator of features of those languages on the interface. Which is the C ABI. That is the generic, common ABI that all languages support. If you want to interact with Rust code, it is no problem to recompile that code with the compiler you use yourself. Except for third party closed-source binary libraries, but those will invariably offer the C ABI.
@@TheEvertw i know that currently the c abi is the common denominator. But that's my whole point. Interacting between 2 feature rich languages with many similar features over the c abi is a huge bottle neck.
@@redcrafterlppa303 Certainly. But I don't think it is even possible to define an ABI that supports most of the features of modern, feature-rich languages. There is just too much variation between their feature sets. And defining such a feature set will immediately make any language that does not support them, obsolete, and make it harder to create a new language because to be useful it immediately needs to be compatible that feature set. Even if it doesn't need those features. Imagine an ABI that supports C++ exceptions, and having to make Rust compatible with it 😱😱😱 In programming, external interfaces need to be simple in order to be generally useful. Sure that introduces headaches for programmers. But it means that old, proven libraries remain useful, and new programming languages aren't burdened by the mistakes of the past. So stop moaning about not having a general high-level ABI for Rust or any other language. It just isn't practical.
Всё-таки, стремление выстроить совместимость с кодовой базой C может сыграть злую шутку. Преимущества Rust становятся не столь очевидными, если под капотом у очередной библиотеки для Rust будет Сишный код, который сам по себе может содержать неопределённое поведение при определённом наборе входных данных.
@@sdramare864 cve-rs занимательная штука. Не знал про него. Насколько я понял, это скорее про баги компилятора, нежели лазейки в концептуальной части языка.
3:04 -- "data races" Not quite. Most data races (not all) are caused by memory being shared across thread boundaries. Rust prevents this in another way, by requiring data that is shared between threads to implement specific traits (Send and Sync).
I have a couple of questions, if rust is as performant as cpp why don't we see it used to produce ultra performant software like chess engines? And why in the chess engines space in particular we don't find any notable contender built with rust? Also why is it really hard to produce ultra compact binaries that don't include the entirety of libraries they use and their dependencies but only the used parts? And why can cargo projects get to 50Gb in size easily when the code files themselves don't exceed a megabyte! I feel like rust has a very long way to go in the optimization route!
Especially if it's generating static binaries it should be more capable of selective inclusion. Maybe they don't even bother to track dependency chains in standard libraries.
@@anon_y_mousse They use a novel concept called feature flags that is cool by itself but sadly is not enough, specially when it's completely up to the crate developer to implement it or not and if implemented it's up to them to specify the scope of the code embedded with the feature.
I think they must develop a compiler flag that performs exhaustive selective inclusion regardless of features and solely rely on feature flags for compile time optimizations.
@@a7madx7 Well, technically it's not a novel feature since C compilers have been using that, albeit as a non-standard feature, for many decades longer than Rust has existed. I'm sure C didn't invent the feature either, but that's actually not what I meant. Each function has a dependency chain of other functions that they use. If the compiler keeps track of that chain, then it could selectively include only the functions that the functions you use use. If you can follow that sentence.
@@anon_y_mousse Yeah I sure can, what you're trying to say is basic dependency management. It's like a dependency tree, maybe add some shake off and it's optimal, and although the concept itself is basic, it's implementation as far as I know is extremely challenging specifically for versioning, also working with a live language that is out there being used is not as easy as lab based development of a new language.
There are several anti-Rust trolls active in the comments. They make outrageous statements like "Rust is stupid for not having a standard ABI", whereas the ONLY standard ABI in existance is the Fortran ABI, as applied to the various computing platforms. Sure, some compiler vendors have promised to keep the ABI their compiler uses constant (e.g. VC++), but this does not mean you can link their binaries to those compiled by another C++. And a constant ABI is only possible for a mature language that is no longer under active development (except for some minor syntactic sugar). It seems there is an active anti-Rust movement going on that is not based in facts or knowledge of Software Engineering. I have never seen anything like it with any other language. It seems some people feel threatened by Rust. Probably because it is such an improvement over C++.
They all just hate follow all those Rust channels so they can write their troll comments. There is even one guy who made several 1 hour long rants about unsafe Rust. I'm not even joking lmao
But if Rust does those checking then in some situations is no longer zero overhead abstraction, it is true that it doesn't have overhead just for the fact of being a higher level of abstraction, but i'ts doing something that doesn't allow you to be as efficient as low level
5:10, why do you say we cannot use the check for valid return of the C++ before using it? We can do the same as you do in Rust. I know channel is about Rust, but dissing C++ where the same thing is more than possible, simply isn't fair in my view.
His point wasn't about being able to do the check, it was about beig able to not do the check. Specifically, that in C++ the check is optional, but in Rust it is mandatory.
I'm not an expert in Rust, but for me C++'s generic programming features looks more powerful than the Rust's one. At least on the first sight. Of course Rust has very powerful macros, which indeed are hard to use, and probably slow to compile. But that is probably another story.
Nah, the Rust generics may remind C++ users of template, but its origin is functional languages such as Haskell. C++ didn't have anything like traits it before C++20 introduced concepts. The closest thing was interface, but there is a significant difference where traits are not part of the type definition, which allows you to assign traits to foreign types.
C++ had traits for ages. It entered into the standard in c++11 but it was there before. It just got a simpler syntax in the modern standard with c++20 with concepts. But concepts are more limited, and you cannot express everything with it, contrary to how powerful all the mtp can be in c++. I think people don't realize how good c++ can be and how far beyond it can go. Rust is close to modern c++, as if someone decided to handpick a limited and safe set of features from c++. And I see the appeal, clearly ! But c++ can go far beyond in different situations. You can even create full templated value semantics program, removing the use of references, handling vectors at compile time...etc You don't even need to use interfaces with static assertion. Concepts facilitate a lot this kind of programs, so you don't need to have dynamic inheritance and can facilitate the code into a more data oriented design. It's just that the language is getting complex with time and for sure, a language with a limited set of good features is a lot nicer for new programs and newcomers.
@@hugotraverson I don't really know what you're referring to, so I might be way off on this... but my understanding is that you couldn't do anything resembling traits, but that you could do statically verified duck typing. Am I missing something?
Because rust is by default statically compiled. You can compile the rust code with dynamic linking to get more or less the same binary size as c or c++, but you would have to link manually just as with c or c++.
Prioritizing safety has doomed the launguge, doesn't matter if the zeolots don't see it yet... Rust codebases are super fragile, refactoring is brutal, and it doesn't deal well with developers being incorrect about initial design choices. I personally think there are a few other major problems, but you hit the largest.
These things are not special to C++. These are only a pattern for any language can implement. That's all. Rust didn't steal anything from anywhere. Your videos are becoming a little bid weird.
C++ indirectly gets something from Rust too, because LLVM has implemented experimental Rust inspired Lifetime Annotations, this then applies to the compiled C++ code. I personally dont want Rust to be a sidegrade to C++, The Carbon team already works on a successor to C++ with interoperability AND memory safety in mind. Let Carbon be to C++ what Rust is to C. That way we all win I think.
Rust is not a C replacement at all at least philosophically. Zig or Odin are more inline with C philosophy. Rust is clearly here to replace C++, which is really really needed.
At 4:00 your example of zero cost abstractions for rust is not zero cost, rust forces you to check if the iterator is valid using the match thing, cpp does not force to check, there is cost in the match
Of course this would depend on a use case, but you could use std::hint::unreachable_unchecked function, it removes all branches that lead to the function, at the cost of causing undefined behavior if it is actually reached. So, it’s not a cost in performance, but can cause undefined behavior if you aren’t careful
Not checking in C++ is a bug. that is covered literally at 4:50 in the video. C++ doesn't force you to be memory safe, Rust does. However, the C++ code will have a bug and potential vulnerability if you don't perform that check. Rust is providing zero cost abstractions over a memory safe implementation. You would need to do the same basic checks inside C++ to guarantee memory safety
@@trapfethen Not checking is not a bug, if they wanted you to check they could very easily force you too, you ignored my point, rust doesn't have zero cost abstraction in the example given, it simply forces you to check the validity of the value at a small cost during runtime, if it was a runtime cost then it can't be zero cost abstraction, and honestly it can even be considered abstraction since if you had taken the same precautions in cpp you would have ended up with the same lines of code in both rust and cpp, the match keyword in the example is literally just a if else statement in cpp
@@technocrat_ "Not checking is not a bug, if they wanted you to check they could very easily force you too" not checking if the return of the max_element function is a null pointer is literally a bug. Second, C++ does not have a mechanism through which it can force you to check the return for Null before accessing it without indirection or bloat. C++s optionals always require extra memory whereas the Rust option does not in this case. The only way c++ can FORCE the developer to handle the potential error is to use additional resources to do so. Rust forces the handling of the error by the language design itself, and in cases where the check is unnecessary within the bounds of the function, the compiler will actually optimize the match function away entirely for you. When someone later changes that code such that the check is required again, it will already be there in Rust; whereas it can be missed in C++. This is literally several zero cost abstractions. Second, zero cost abstractions refer primarily to memory footprint anyway. As already pointed out, Rust does not require any additional memory to represent an Option than it does a &int by itself. Literally zero cost even when you DO use it.
Regarding traits and concepts - wasn't it the other way around? Rust had traits from get go while C++ introduced concepts waaaaay later in 2020 or something like that?
(It's a quote from Kate Gregory in one of her many C++ conference talks here on the tubes. But regardless of the reference, I would think most people who have dealt with RAII will get the joke and agree that RAII is a terrible name.)
The biggest problem with Rust is the lack of Rust developets. We wanted to start a Rust project at work, but it's not feasable, because we simply lack developers who are familliar with Rust. We have a bunch of C++ developers, but they all shrug at the idea of working with Rust.
That check is semantically equivalent to the Match statement in Rust. The difference is that RUST recognizes the potential error and FORCES you to handle that case while C++ is more than happy to allow you to write it in the buggy way with no warning that you messed up. These little gotchas can be a lot more subtle than this, especially over a large enough codebase; hence the 70% statistic put out by Google, Microsoft and other big tech companies.
Rust generics are not a refinement of C++ templates. They are just glorified macros. C++ also has constexpr which is far more powerful for generic programming.
@@JG-nm9zk Rust templates are essentially just compile-time macros (instead of simple preprocessor macros). They don't allow you to do the kind of powerful metaprogamming you can do in C++ with templates, constexpr, consteval, etc.
I don't think you really understood then. Rust implicitly does the new/delete for you. They are still there under the hood. You can force rust to drop something earlier than you would have normally by using scopes (or by calling drop which is basically the same as delete), but Rust simply ensures that you can't try and access something which either hasn't been created or hasn't been deleted yet.
💛I had the pleasure of being in the same room with him and listening to what he said. There was a Fireside Chat at Morgan Stanley's Budapest office around 2019.
@@AdamFiregate That’s awesome. He is easily my personal favorite computer scientist of the modern era. I love his approach to problem solving and I believe he is an exceptional teacher. Love his books!
What's so insane about them? The 'max_element' example looks very functional easy to read to me. I guess there are very ugly edge cases? Generally I prefer iterators over raw for loops in any language. Most of the time I declare a counter 'i', then get the i-th element from an array and never use i again. Might as well use the languages for-each construct. Less error prone too imo
@@NabekenProG87 Its a simple contrived exampled, in which yes, it is much simpler to read. In reality though most for loops are not this simple, and often you end up with a large chain of iterator functions thats as hard if not harder to reason than a simple loop.
@@hectormejia499 Ah, thx for the info. Never used 'functional' style in C++ all that much. I think it's quite usable in Rust and assumed C++ was similar, just more .begin .end
I started learning Rust for a project of mine. The moment I realized it has incorporated a lot of stuff from C++ I dropped it like it was a ticking bomb. I am sticking with the old good C and Go for anything web related.
I feel you about wanting to stay away from C++ but having done a good bit of rust (only for personal projects though), I haven't felt the presence of any of the things I don't like from C++.
Rust IS the new C. Where C++ frivolously added features "because we can!" Rust followed the disciplened approach of "because we should" and "perfection is achieved, when there is nothing left to remove".
Rust looks neat but at the same times is a brainfuck "wtf is this" kind of language. Especially when your new to it. The resource management of C++ is very elegant, the rust version is... just weird. Sure, it works, but the syntax is so unlike any other language that it just creates a steep learning curve right there to even grasp the concepts and make proper use of it. The C++ syntax for the same thing is just simpler to grasp. Still gonna learn and use rust but definitely not a fan of some of it's weird syntax.
Rust is following a trend from many other newer languages, like Go. Namely they try to follow English Subject-Verb-Object word order more closely in a lot of places. In C you have: "Integer A equals 5" (int a = 5;) In Rust you have: "Let A be an integer equal to 5" (let a: int = 5;) And thanks to type inference you can eliminate redundant parts of that: "Let A equal 5" (let a = 5;) Even C++ has started to adopt this way of doing things with lambdas and trailing return types for functions.
@@NovemberIGSnow The order of variable declarations in C/C++ dates back to the 70s. Back then, C was a high-level assembler that worked with blocks of memory for which names were given. Moreover, in the first versions of C (before the C11 standard), it was necessary to define variables at the beginning of the code block. In essence, the description of the memory structure was primary, and the label of this memory was secondary. C++ inherited this. And for modern languages that were already designed taking into account automatic type inference at runtime or at compilation stage, type indication is optional. In this case, the name of the variable, as a certain algebraic entity, comes first. And the type indication should be considered as a kind of restriction, which in most languages (including C++) is written through “:”
@@RustIsWinning Look at 1:31. The way that C++ is written, in a memory safe manner, is elegant. The EXACT same rust snippet is "wtf is that?" kind of code. Like instead of giving a normal readable "new object in this scope" (which the make_unique does), in rust you have something names a "box".... What is a "box"? Sure, if you get into the rust-slang that might be normal to you. Now go a step further into borrowing. make_shared is quite intuitive and easy to grasp, try that with the way you "barrow" in rust. Sure, lots is just getting used to the difference in slang and then getting used to it's weird syntactic way of writing. But exactly those two don't particularly help rust. At least not for me.
I find C++ template system (used along with concepts) much more flexible and powerful than Rust generics + macros. In C++ you are able to iterate much faster through different implementations and when the dust has settled down you can define various concepts to "formalize" the interface, whereas in Rust you would need to strictly define the interface (traits) to even compile the code. Also C++ constexpr is much better than anything Rust has to offer. Rust macros are a language on their own and an expert only feature, whereas in C++ just putting a constexpr specifier on a function, nowadays, makes it compile-time executable in most cases.
Yup, Rust leads to fragile codebases, and barriers to refactoring design. I suspect it's why the Servo project failed. It wasn't even a super low level problem space, Servo wasn't as OS... and yet, it failed.
I don't agree. Due to the aggressive inlining in Rust, and const propagation, without constexpr, a lot of things will be calculated at the compilation stage. But for complex cases, macros are still better. For example, it is possible to call a third-party solver from a macro and perform complex calculations which are inaccessible to the compiler.
@@cyberpunkspike Servo is in active development right now? My earliest rust code is already five years old and has not required any updates since deployment, and the speed of development and refactoring in Rust are faster than in C++, not slower. The only real drawbacks are the compile times, and the learning curve. New programmers can make "useful" code in C++ faster than they can in Rust, but the difference in soundness between the two pieces of work will be night and day. Given enough time, they will be more productive in Rust than in C++. The confidence in their code will be far higher as well. Potential memory issues will be segregated to "unsafe" blocks which will be flagged by your code review process for a more thorough look to verify the memory safety guarantees have been upheld. That is before you even begin to tackle the C++ flavor problem, multi-threading safety, etc.
The problem is C++ abstraction is not zero-cost. If you use virtual functions, you pay for extra vtable storage and lookup cost during runtime. Rust didn't offer anything like virtual functions imo.
Rust does have something like virtual functions via trait objects and dynamic dispatch, though it's not exactly the same as C++. I believe C++ stores the pointer to the vtable as part of the object itself, whereas Rust stores the pointer to the vtable alongside the pointer to the object. I believe this is why Rust currently doesn't support casting from a trait object to another trait object, as Rust only knows the location of the vtable for the object's implementation of the first trait, not the second.
@@NeuwDk You are right, I am not very familiar with dyn trait, I was thinking about impl trait, which is more like CRTP in C++, guess dyn trait is equivalent to virtual functions and impl trait is eq to CRTP.
@@xiahualiu No, your concept of "zero-cost abstraction" is wrong, and your comparison actually does not make sense in the first place. 1) As you said, Rust does not provided "dynamic polymorphism via OOP". Therefore Rust has nothing to compare against C++'s virtual functions. End of story here; zero OOP support in Rust cannot be used against whether C++ really adheres to zero-cost abstraction or not in any way. Of course, Rust provides other means to achieve dynamic dispatching, but then you also have to compare that against C++'s dynamic dispatching mechanism. A whole different topic. 2) Zero-cost abstraction, or to be more rigorously speaking "zero-OVERHEAD abstraction", roughly means "What you do use, you couldn't hand code any better" as stated in the video 03:37. If you think virtual function in C++ is not zero-cost/zero-overhead, then you have to show that dynamic dispatching via OOP can be implemented cheaper than what C++ has right now, a vtable implementation. When Java was the New Kid on the Block, there were many discussions about this. Can we do dynamic polymorphism via OOP without vtable? If so, is it better? You can look up those discussions. 3) There do exist few infamous cases where you can make a reasonable argument that C++'s zero-cost/zero-overhead abstraction breaks down at some special cases. But it is not done how you stated in the OP. What you wrote is plainly wrong.
To be clear, I meant std::variant & std::visit in 1). It is a valid discussion to figure out what is the best way to achieve dynamic dispatching; is it by dynamic polymorphism via OOP(virtual functions)? by static polymorphism(CRTP)? by dynamic dispatching(variant & visit)? It, however, is a discussion about design choices between different approaches, and has nothing to do with what approach is zero-cost/zero-overhead abstraction or not.
template system in c++ is a fucking nightmare. in c you have the macro system which will pre process your files. It's a pain in the ass to begin with because it's a simple "find and replace" program. But you can save the source code output after the pre processing and have a look at it. With c++ on the other hand, after the preprocessing step it will do the template resolution by changing your source code with whatever the template evaluates to. You'll never be able to see the source code after the templates have been applied. So when you get a compilation error in c++, it will point to to errors referencing that intermediary source that you have no access to. Fuck c++... And fuck cmake as well
Inheritance and all it's subsequent worms are what OOP is to most people it seems, I'm glad Rust doesn't have them. I might maybe possibly forgive single inheritance but anything more I despise lol
I mean, technically Rust _does_ have a form of inheritance: interface inheritance via traits. By implementing a trait on a type, you are inheriting the public interface defined in the trait which lets you refer to that type as the trait alone, either statically via generics and monomorphisation, or dynamically via trait objects and dynamic dispatch. What Rust lacks is _data_ inheritance, where you can have a type inherit some _data_ defined in another abstract type. This was a conscious design choice, as, for some reason, data inheritance is typically what most beginner developers reach for first when trying to write some abstraction over some code, which causes innumerable problems later on when you suddenly need to change what data is included in the abstract type when trying to extend it with a new concrete type, breaking several other concrete types in the process. By only offering interface inheritance, Rust forces each and every concrete type to solely worry about its own data, which lets you change the data in one type without completely breaking other types.
Given that Rust was started in 2006, and C++ concepts came out in 2020, I'm going on a hunch to say that C++ stole Rust for point #3 😆 (Okok, C++ had templating, Rust made it better with traits, and then C++ stole traits to make Concepts)
No, your hunch is not correct. You can find earlier researches about "C++ concepts" or other similar constructs for different programming languages before Rust's introduction of Traits.(*) The original concept(no pun intended), which got implemented as C++ Concepts/Rust Traits/Swift Protocols, is NOT invented by neither C++ nor Rust nor Swift. It was proposed in the '80s, and first implemented by Haskell people. Then, it has researched, and its implementation has evolved through a very long time until it landed on C++, D, Rust, Swift, and others. (*) For example, Douglas Gregor, Jeremiah Willcock, and Andrew Lumsdaine, "Concepts for the C++0x standard library: approach", January 2006.
Rust was first made public in 2015, regardless of when the initial development was being worked on. C++ had concepts in Boost before 2006. If you want to argue that it wasn't standard, then go for it, but it's an irrelevant argument because the best part of the ecosystem for C++ is that so many libraries exist to allow you to accomplish tasks without waiting years for the standard to be updated.
It is insanely fast and being safe doesn't make it slower. Actually, being safe makes it faster sometimes because you know 2 pointers don't overlap and you can do cache optimizations
Get your *FREE Rust training* :
letsgetrusty.com/bootcamp
Not "stole", but "borrowed"
I see what you did there...
It needs to be a copy, what if Rust outlives them???
Good one
Nice
It's true, i checked!
Rust absolutely took RAII, smart pointers, zero overhead abstractions from C++. However I would argue that Rust's generics are more likely been inspired by ML languages like Ocaml and Haskell. I might be wrong about this so please correct me if Im wrong.
The fact its compile time and not runtime without any dyn..
That's probably C++ and the syntax is the same
@@nevokrien95 What do you mean? It's compile-time in OCaml and Haskell as well.
Rust's generics is heavily inspired by the ml languages, like ocaml. the whole type system is
the first version of the rust cimpiler was written in ocaml, so yeah I'd argue ocaml and cpp rust's parents
@vytah I think at least with Haskle it's a dyn so there is runtime type information. Because for things like structs it's defined as an interface.
Like you don't need to concern urself with whether something is dyn or not
But with rust you get the C++ style compile the whole dam function from scratch for that type.
I wish you hadn't blurred your section titles at the beginning. I get that it's good for the algorithm to keep people watching, but it doesn't feel like it's optimized for teaching.
> Rust only allows you to allocate resources using RAII constructs.
There are raw alloc/dealloc functions; they're just unsafe.
> Rust has made generic programming more accessible and safer, while maintaining its power...
There are important things that you can do with C++ templates but not with Rust generics. Templates offer "compile-time duck typing", which is why they're so flexible but also why their compiler errors are noisy. Rust doesn't (yet?) have specialization, and its const features are more limited. Maybe this is nitpicking of me, but your channel is prominent on TH-cam, and I think it's important for prominent Rust advocates to get these little details right. Experienced C++ folks tend to pick up on this stuff, and it makes them feel like they can't trust Rust folks to talk about tradeoffs fairly.
Yeah, I had issues with these points too. That said, I forgive him because RAII was mentioned _and I love RAII_ .
When learning Rust (while already being familiar with C++) I have came to terms with that generics are a really focused tool, and while they are not insanely powerful like templates, they work quite well when taken in context of the entire language (or maybe more precisely, type system). That said, I am not on the level of some C++ users that can do _anything_ with some templates that are unreadable to anyone but others of their kind lol.
Yes, Rust generics are limited because metaprogramming is achieved via other techniques. Maybe this video needed a point #4?
Well, you can't trust Rustaceans to speak even-handedly. If it's not lying by omission, it's outright propaganda via slurs against better languages. For instance, the crack about better syntax is patently false as the irregular syntax of Rust makes it harder to read and it's noisier in either case.
@@anon_y_mousse Clearly you're speaking even-handedly here right?
@@Tempestissiman Compared to the majority of Rustaceans who only know Rust and maybe one other language which they switched from after 6 months or less. Even those supposed C++ converts who only ever used C++ as C with classes I would say don't know what they're talking about.
What I really miss in Rust is stable ABI, and creating libraries in Rust for Rust apps, to prevent creating Rust apps as one big monolith
A great reason to not use a degenerate launguge like Rust, use C or C++.
@@adrian_sp6def I don't have a problem with pure rust apps being monolithic. It's more about existing a library API for me.
CrABI is planned, which is supposed to be a superset of the C ABI
There are multiple methods to have a stable ABI in Rust. One of the core issues with C-ABI is how terrifyingly un-defined/compiler dependent you actually are. If you want an ABI right now in Rust, *you* have to define what you *mean* by an ABI. This is true for "true ABI-stable" libraries elsewhere (glibc for ex.) which have to do a lot of soname magic to custom define all the compatibilities. So, for the easy path: "just compile the world and cargo/rust do the internal ABI" but if you want an actual ABI to expose externally, define it! There are a few different options depending on what you want out of your ABI-API specifically because there are levels of how much you actually *care* about ABI. Work is also ongoing on a syslinker-aware ABI called "crABI".
For other levels of ABI stability:
* Rust Crate abi_stable: "For Rust-to-Rust ffi, with a focus on creating libraries loaded at program startup, and with load-time type-checking."
* Rust Crate stabby: "stabby is your one-stop-shop to create stable external binary interfaces for your shared libraries easily, without having your sum-types (enums) explode in size.
* The Extism ecosystem: If you are looking more for plugins/modules to a mian-app type thing
* more besides for more niche uses (such as "USB device firmware protocol packets" and more!)
Do you mean that Rust doesn't have dynamic linking?
Ironically, C++ just got a large proposal called Safe C++. It includes safety-by-default and the unsafe keyword, borrows and lifetimes, MIR and a borrow checker, destructive moves and relocatable types, send/sync traits, and more. If it passes, soon C++ will have stolen Rust's best features right back!
immutable by default too?
Another proposal that gets rejected in the end? Haha 😂
@@HermanWillems Sort of? Variables are still mutable by default, but when you call methods or pass them as parameters they are immutable unless you use explicit syntax to make a mutable reference or borrow.
Só it's getting more bloated yet. Nice!
@@lucascamelo3079 I just read the proposal and it's big copium lmao. They put as many Rust features as they wanted in their "safety mode". If C++ devs want to make their language look like Rust why not use Rust 🤣
Why is every video on Rust the exact same? Every Rust content creator seems to just re-hash the same three talking points over, and over, and over, and over again. Like, I could already guess two of the three points within three seconds of reading the title.
C++’s best feature is not being rust
Why do you not like Rust?
@@svenyboyyt2304 I like rust but sometimes the freedom is nice.
A HUGE thing that Rust is missing is dynamic linking of libraries and stable ABI. Everything compiles to a huge binary, which is ok (and even desirable) for big apps but much less so for small tools and helpers.
Of course you can use dynamic linking. It's very useful for fast debug builds in large projects. The problem is that it's not recommended to use dlls compiled on different compiler versions (the ABI thing), meaning you probably need one party to compile every rust app (such as a distro). Rust projects are also famously lazy, leading to many tiny and outdated libraries, that cause version conflicts for distros. Static linking has some security and performance advantages, is not as large as you think due to dead code analysis, and is the standard. Maybe there should be a push for everyone to either update their crates or somehow mark them as inseparable.
@@CjqNslXUcM If you want to dynamically link something, that implies a lot of boilerplate, unsafe code and is a decently-size PITA overall - feel free to correct me if I'm wrong though. Not sure how panic unwinding works in that case either.
Static linking is nice but for small system tools-wide like those of GNU, dynamic linking is the only reasonable way as there will be thousands of them.
No dynamic linking is a huge no-no for certain kinds of software, like games.
Rust does have dynamic linking, in fact you can even dynamically link using the C ABI. The current limitation is that Rust doesn't provide its own stable ABI for dynamically linking higher level abstractions.
Finally, there is an unofficial stable ABI provided by Stabby (Stable ABI) that's just a simple dependency you can include in your project if you want it.
@@zactron1997but if I lose on all the abstractions, then what advantage does rust have over C on that matter?
Sadly one of the things Rust still hasn't stolen from C++ is its capability for Compiletime-Programming. Rust's const still feels like C++14 constexpr which is well 10 years old. Really hope to see Rust improve in that regard.
I'm curious, what is missing from Rust's const?
@@NetherFX Memory allocations for example
@@MegaKillzor Can you explain briefly plz? I wd like to learn, I haven't gone through consts much
@@jackthereaper9379 As far as I’m aware, rust const fns (functions that may run at compile time) can’t use heap. Eg, you can’t use a Vec or String.
@@moustachescarzokay, got it thanks
All the examples you shared really demonstrate the elegance of Rust
70% of bugs are memory safety issues because of c++ or becaue of ugliness windows C API where struct names are sequence of random characters someone has written by smashing keyboard by hand ?
I presume you are referring to "Hungarian Notation" where the datatype of the variable is encoded into the name. This certainly is an ugly standard, and now that we have PLS there is no more need for it, but Microsoft loves their "forever" backward compatability (nevermind that it doesn't actually work) and so will likely never change.
that's just your de-compiler.
@@ColinFox at least it works better than Linux backwards compatibility. You can't run a binary from 2 months ago on a bleeding edge distro.
So now Microsoft is trustworthy? After decades of being untrustworthy and dishonest. And let's not forget that Microsoft has milked c++ into oblivion from late 80's. So it's c++ fault not Microsoft engineers who used? Such an extreme example of hypocrisy. Is rust gonna magically make stupid people smart? I don't think so.
This was a nice video, I like Rust, I'm glad it exists and I'll try to learn some in the future. To be honest the only reason I haven't tried learning it so far is because the code just looks ugly to me. I admit the generics look cleaner though.
Also the argument at 5:00 doesn't seem valid to me, any good C++ programmer would tell you not checking the return value of a non [[nodiscard]] function is a bug in itself. Had you just checked to make sure the iterator was valid to dereference, it would have been the equivalent to Rust's match case. It seems like you intentionally wrote two different pieces of code to do two different things, and then tried to compare them as if they did the same thing?
Rust forces you to check the return value. That's the point.
@@31redorange08 And yet there's nothing to stop a good programmer from always checking it regardless. There's also nothing to stop an individual compiler vendor from checking it by default, nor is there anything to stop programmers from using the existing tooling for both C and C++ to check it outside of the compiler. Write a makefile template and copy it for every new project and you won't have to remember any individual steps in setting up checks.
C++ template syntax with concepts or auto deduction is actually more readable than Rusts edition... As far as I'm concerned this Rust video was already outdated even before it came out.
Hahaha no 😂
@@RustIsWinning And the church of blind faith rust god responds :)
@@DerDoMeN go write more awful concepts in template hell while we write simple bounds like any other generic programming language
@@RustIsWinning This is a C++ template function: void hoho( auto x )
And this: void hoho( std::integral auto x )
At least learn the latest standards of languages before spitting on them...
And yes, I've used Rust and my verdict was that it's a promising educational project that is far too over hyped and is thereby causing much more damage than it does good. (exhibit a: you)
Rust to programming is like crypto to banking: the best thing that it gives is a kick in the but to complacent old timers to evolve and that's about it.
It has some good ideas but in the end it's just another toy one trick pony that preferred to go down the revolution path instead of evolution of others for the short term gain of few and long term loss of many.
And yes, C++ template meta programming (which you're probably referring to as you probably don't know that there is a difference between templates, concepts and template meta programming...) can get convoluted really fast but even that is only one of the tools in the toolbox which shouldn't be overused but is is great when really needed.
@@RustIsWinning I cast Generic Specialization. Begone beast.
C++ and Rust are pretty cool
First thought after reading the caption: Undefined behaviour? )
You can see the RAII in VSCode, there’s an option showing when drop() is called on an object
Rust has manual free types but its all in unsafe. The main thing rust does with RAII that C++ is not the restriction but rather the checking
In C++ when u want to pass refrences u do a .get() or even give a refrence. But nothing actually checks ag9nst uae after free here.
RAII actually makes it easier to do use after free when passing pointers
glad this language arrived when it did, bridging the web and hardware levels sucks sometimes, it's a big world down there
Rust is great for writing self-contained applications. The lack of a way to expose functionality to C limits it for writing libraries. That's a shame, because this is what prevents us rewriting core Linux libraries and makes it harder for Linux kernel development.
You make great points, and it also prevents us from gaining community experience living with and maintaining production Rust codebases. That lack of battle tested systems level projects, is why there is opposition to Rust adoption in existing codebases.
To export functions to the C ABI, is there 'extern "C" {your rust function}' or are you talking about something else?
@@cyberpunkspike That and just general hate for Rust for some reason. Even many previous proponents of Rust have basically turned against it. Not that's because it's not novel enough to be "cool" any more, or because of the foundation drama, but looking at (for instance) the Primagens views on Rust now vs 2 years ago is pretty much a complete 180.
I don't get your point. You can easily expose functionality to C, by using the C-ABI. It's no different from C++ in that regard.
It IS possible to expose functionality to C from Rust. So I don't get what the problem is. If you expect painless interaction between two different programming languages, that is impossible for many reasons. You will always need to write glue code to massage around the differences in platforms. If only to wrap C enums into Rust enums, or C strings into Rust strings. Libraries exist to help with this.
One problem is the persistent love for huge, monolithic programs that do everything. Monoliths are very hard to refactor to a different programming language. That is one reason why it is usually better to split large programs into several, smaller programs.
Specifically for the Linux kernel, I think it is definitely useful to implement large & complex beasts like an USB stack, TCP/IP stack, file system or display driver in Rust, but not simple stuff. The overhead of moving between the two abstractions (C and Rust) will become a burden if e.g.part of the task switching code is in Rust and another in C. That just doesn't make sense. Neither does it make sense to write part of the ext4 file system in C and the rest in Rust. Sadly, for those projects, you have to move to another language in one go, all-or-nothing. To try and migrate file-by-file is simply not possible, and that is not Rust's fault. The idea that you could do that is totally unrealistic.
Funny you mention templates and generics because to me thats one of the weakest parts of Rust. "Generic specialization" Rust has been working on it since 2014(still in nightly). Rust's generic/traits/async/const features do not work well together. Everything that makes using more than one feature at a time less painful is in a crate or in nightly.
What color is your runtime? what color is your function?
Everyone seems to want programmers languages to have no flaws or shortcomings, and if they do have a flaw they deem sufficiently important, then the whole language is garbage. A childish attitude imo. I’m not saying it necessarily applies in your case, but it’s an impression I get from many of the comments here and elsewhere.
@@kevinmcfarlane2752 Don't pussyfoot around and just call me childish or just say you don't know what you are talking about.
I wish your variables' names will be blurred from now on
7:03 bro talks about the monomorphism concept
I think one big issue holding compatibility with other languages back is the lack of a defined abi.
Not having an abi prevents other languages to support rust as a direct and efficient ffi target.
For example I am currently designing a language similar to rust but with some personal changes. I would like to support many languages as native abi targets allowing for seamless integration and mixing of code written in the different languages. With a defined abi even direct inline mix and match code would be possible. As my language is similar to rust and holds many of the same guarantees even safe to safe function interaction would work.
You must be the third person saying this. It is complete nonsense. Even C++ doesn't have a stable ABI, in spite of efforts by e.g. M$ to push theirs through.
Ever since Fortran, ALL compiled programming languages have supported the Fortran ABI for calling functions in other link units. Trying to define ABI's for other languages are always attempts at vendor lock-in, because it means you can only use the generated link units from their compiler platform. The moment a more advanced ABI is adopted as standard is the moment that C (and Fortran) become unusable. That day is still a long way off.
Also, ABI's stifle innovation, because when a language gets a new feature, it usually means the ABI must change to accommodate it. That some compiler vendors for C++ have frozen their ABI's means C++ is truly a mature language with only syntactical innovation.
It is good to have a stable ABI so library vendors can ship closed-source, pre-compiled code. But the Fortran ABI fulfills that role marvelously. It has done that for 60 years, and will probably continue to do so for another 60.
@@TheEvertw the thing with the c abi is that it's quite limited. It only defines a handful of things to work with.
The biggest downside is that it doesn't support lifetimes and generics. This means that there is currently no abi that qualifies to rusts safety guarantees meaning that any ffi needs to be considered unsafe. Even when the other languages defines the same rules. The 2 cannot communicate the lifetime relationship. The second thing are generics which have the same problem with lack of communication. There is no abi that allows compilers to communicate which generic specialization the other needs.
Sure a fixed abi makes innovation more difficult but correct me when I'm wrong but didn't rust solve abi incompatibility with itself using the Edition system where you can combine projects of different rust versions and abis without updating source code.
@@redcrafterlppa303 True, and the same holds for other programming languages. If you want other code to interact with your code, you will need to use the lowest common denominator of features of those languages on the interface. Which is the C ABI. That is the generic, common ABI that all languages support. If you want to interact with Rust code, it is no problem to recompile that code with the compiler you use yourself. Except for third party closed-source binary libraries, but those will invariably offer the C ABI.
@@TheEvertw i know that currently the c abi is the common denominator. But that's my whole point. Interacting between 2 feature rich languages with many similar features over the c abi is a huge bottle neck.
@@redcrafterlppa303 Certainly. But I don't think it is even possible to define an ABI that supports most of the features of modern, feature-rich languages. There is just too much variation between their feature sets. And defining such a feature set will immediately make any language that does not support them, obsolete, and make it harder to create a new language because to be useful it immediately needs to be compatible that feature set. Even if it doesn't need those features. Imagine an ABI that supports C++ exceptions, and having to make Rust compatible with it 😱😱😱
In programming, external interfaces need to be simple in order to be generally useful. Sure that introduces headaches for programmers. But it means that old, proven libraries remain useful, and new programming languages aren't burdened by the mistakes of the past.
So stop moaning about not having a general high-level ABI for Rust or any other language. It just isn't practical.
Всё-таки, стремление выстроить совместимость с кодовой базой C может сыграть злую шутку. Преимущества Rust становятся не столь очевидными, если под капотом у очередной библиотеки для Rust будет Сишный код, который сам по себе может содержать неопределённое поведение при определённом наборе входных данных.
Любой unsafe блок может его содержать. Да и не unsafe тоже, есть же cve-rs крейт.
@@sdramare864 cve-rs занимательная штука. Не знал про него. Насколько я понял, это скорее про баги компилятора, нежели лазейки в концептуальной части языка.
Please don't tell me oop, please, oop is socks 🙏
3:04 -- "data races"
Not quite. Most data races (not all) are caused by memory being shared across thread boundaries. Rust prevents this in another way, by requiring data that is shared between threads to implement specific traits (Send and Sync).
Very good montage man, I'd like to see a video with some projects for beginners requiring to use some of the rust extensive features
Text sounds like you generated it with chat gpt
I have a couple of questions, if rust is as performant as cpp why don't we see it used to produce ultra performant software like chess engines?
And why in the chess engines space in particular we don't find any notable contender built with rust?
Also why is it really hard to produce ultra compact binaries that don't include the entirety of libraries they use and their dependencies but only the used parts?
And why can cargo projects get to 50Gb in size easily when the code files themselves don't exceed a megabyte! I feel like rust has a very long way to go in the optimization route!
Especially if it's generating static binaries it should be more capable of selective inclusion. Maybe they don't even bother to track dependency chains in standard libraries.
@@anon_y_mousse They use a novel concept called feature flags that is cool by itself but sadly is not enough, specially when it's completely up to the crate developer to implement it or not and if implemented it's up to them to specify the scope of the code embedded with the feature.
I think they must develop a compiler flag that performs exhaustive selective inclusion regardless of features and solely rely on feature flags for compile time optimizations.
@@a7madx7 Well, technically it's not a novel feature since C compilers have been using that, albeit as a non-standard feature, for many decades longer than Rust has existed. I'm sure C didn't invent the feature either, but that's actually not what I meant. Each function has a dependency chain of other functions that they use. If the compiler keeps track of that chain, then it could selectively include only the functions that the functions you use use. If you can follow that sentence.
@@anon_y_mousse Yeah I sure can, what you're trying to say is basic dependency management. It's like a dependency tree, maybe add some shake off and it's optimal, and although the concept itself is basic, it's implementation as far as I know is extremely challenging specifically for versioning, also working with a live language that is out there being used is not as easy as lab based development of a new language.
Good ol' Bjarne Schrawrschwarp
Is this rust admitting that C++ has always been better ?
Found the hate follower lol
I ordered The Book. And when I order a print when there is a copy online it means I'm about to get serious. Wish me luck.
what about dynamic libraries??
how did Rust steal those from C++
@@professionalcat9928 Well... technically it did steal C++'s lack of a binary ABI.
@@cyberpunkspike C++ has no problems to deal w/ C ABI, but for Rust, it's pure abomination :))
There are several anti-Rust trolls active in the comments. They make outrageous statements like "Rust is stupid for not having a standard ABI", whereas the ONLY standard ABI in existance is the Fortran ABI, as applied to the various computing platforms. Sure, some compiler vendors have promised to keep the ABI their compiler uses constant (e.g. VC++), but this does not mean you can link their binaries to those compiled by another C++. And a constant ABI is only possible for a mature language that is no longer under active development (except for some minor syntactic sugar).
It seems there is an active anti-Rust movement going on that is not based in facts or knowledge of Software Engineering. I have never seen anything like it with any other language. It seems some people feel threatened by Rust. Probably because it is such an improvement over C++.
They all just hate follow all those Rust channels so they can write their troll comments. There is even one guy who made several 1 hour long rants about unsafe Rust. I'm not even joking lmao
What do you think about the Android development ecosystem for rust.❤❤😢
But if Rust does those checking then in some situations is no longer zero overhead abstraction, it is true that it doesn't have overhead just for the fact of being a higher level of abstraction, but i'ts doing something that doesn't allow you to be as efficient as low level
The checking is done at compile time, not at run time. "Zero-overhead" means no overhead _at runtime._
@@TheEvertw exactly
Thank you for this greatly explained and concise summary!
5:10, why do you say we cannot use the check for valid return of the C++ before using it? We can do the same as you do in Rust. I know channel is about Rust, but dissing C++ where the same thing is more than possible, simply isn't fair in my view.
His point wasn't about being able to do the check, it was about beig able to not do the check. Specifically, that in C++ the check is optional, but in Rust it is mandatory.
@@SimonClarkstone This I agree. Fair enough.
Дякую Богдане! And again i'm hearing video while coding my rust project)
I'm not an expert in Rust, but for me C++'s generic programming features looks more powerful than the Rust's one. At least on the first sight. Of course Rust has very powerful macros, which indeed are hard to use, and probably slow to compile. But that is probably another story.
"Notice the clean syntax" come again?
I love C++ `auto` and `concept`s:
```
auto foo(FmtDisplay auto t) {}
```
just use std::fmt::Display; and it's no more than
Sync + Send + 'static
I mean it's not pretty, but it is readible
Imagine not knowing what generic programming is 😂
Nah, the Rust generics may remind C++ users of template, but its origin is functional languages such as Haskell. C++ didn't have anything like traits it before C++20 introduced concepts. The closest thing was interface, but there is a significant difference where traits are not part of the type definition, which allows you to assign traits to foreign types.
C++ had traits for ages. It entered into the standard in c++11 but it was there before. It just got a simpler syntax in the modern standard with c++20 with concepts.
But concepts are more limited, and you cannot express everything with it, contrary to how powerful all the mtp can be in c++.
I think people don't realize how good c++ can be and how far beyond it can go. Rust is close to modern c++, as if someone decided to handpick a limited and safe set of features from c++. And I see the appeal, clearly !
But c++ can go far beyond in different situations. You can even create full templated value semantics program, removing the use of references, handling vectors at compile time...etc
You don't even need to use interfaces with static assertion. Concepts facilitate a lot this kind of programs, so you don't need to have dynamic inheritance and can facilitate the code into a more data oriented design.
It's just that the language is getting complex with time and for sure, a language with a limited set of good features is a lot nicer for new programs and newcomers.
@@hugotraverson I don't really know what you're referring to, so I might be way off on this... but my understanding is that you couldn't do anything resembling traits, but that you could do statically verified duck typing. Am I missing something?
i don't know why rust's simple hello world compiled executable is so large compared to c or c++ 😅
Because rust is by default statically compiled. You can compile the rust code with dynamic linking to get more or less the same binary size as c or c++, but you would have to link manually just as with c or c++.
because rust links a lot from std as static import.... rust has some built in thinks compare to c++. Which you will in period of time anyway....
what compile options did you use? if you do debug then yes its huge.
My dream language is rust without memory safety.
Prioritizing safety has doomed the launguge, doesn't matter if the zeolots don't see it yet... Rust codebases are super fragile, refactoring is brutal, and it doesn't deal well with developers being incorrect about initial design choices. I personally think there are a few other major problems, but you hit the largest.
So a language with verbose and ugly syntax and no memory safety?
@@rastaarmando7058 it only seems ugly at the start, once you use it for a while it's quite nice
Just write unsafe code in Rust then
Why would you want no safety? If you want to do something memory unsafe, then just do unsafe Rust.
rust analyzer just keeps hogging on my ram
Rust package management system is tailored to Windows and Mac. Linux was an afterthought.
Copy and paste this command to your terminal. Its safe. Trust me bro.
Everyone's favorite programming language sucks, except mine.
Define steal
Not borrowing.
Please fix the redundancies from the LLM before recording… It’s so blatantly obvious.
These things are not special to C++. These are only a pattern for any language can implement. That's all. Rust didn't steal anything from anywhere. Your videos are becoming a little bid weird.
Intro was epic 😂
C++ indirectly gets something from Rust too, because LLVM has implemented experimental Rust inspired Lifetime Annotations, this then applies to the compiled C++ code. I personally dont want Rust to be a sidegrade to C++, The Carbon team already works on a successor to C++ with interoperability AND memory safety in mind. Let Carbon be to C++ what Rust is to C. That way we all win I think.
I think Rust to C++ and Zig to C is a better comparison
C++ should be C++ new successor, with the new standards getting more and more memory safety features in them.
@@RomanAvdeevX agreed
Rust is not a C replacement at all at least philosophically. Zig or Odin are more inline with C philosophy. Rust is clearly here to replace C++, which is really really needed.
@@aymanougri1225 sadly old code bases still do be old code bases. i also doubt its possible to introduce rust like error handling to it in any version
Classes? ;D
I wish they had stolen better syntax.
That's good.
At 4:00 your example of zero cost abstractions for rust is not zero cost, rust forces you to check if the iterator is valid using the match thing, cpp does not force to check, there is cost in the match
Of course this would depend on a use case, but you could use std::hint::unreachable_unchecked function, it removes all branches that lead to the function, at the cost of causing undefined behavior if it is actually reached. So, it’s not a cost in performance, but can cause undefined behavior if you aren’t careful
Not checking in C++ is a bug. that is covered literally at 4:50 in the video. C++ doesn't force you to be memory safe, Rust does. However, the C++ code will have a bug and potential vulnerability if you don't perform that check.
Rust is providing zero cost abstractions over a memory safe implementation. You would need to do the same basic checks inside C++ to guarantee memory safety
@@trapfethen Not checking is not a bug, if they wanted you to check they could very easily force you too, you ignored my point, rust doesn't have zero cost abstraction in the example given, it simply forces you to check the validity of the value at a small cost during runtime, if it was a runtime cost then it can't be zero cost abstraction, and honestly it can even be considered abstraction since if you had taken the same precautions in cpp you would have ended up with the same lines of code in both rust and cpp, the match keyword in the example is literally just a if else statement in cpp
@@technocrat_ "Not checking is not a bug, if they wanted you to check they could very easily force you too" not checking if the return of the max_element function is a null pointer is literally a bug. Second, C++ does not have a mechanism through which it can force you to check the return for Null before accessing it without indirection or bloat. C++s optionals always require extra memory whereas the Rust option does not in this case. The only way c++ can FORCE the developer to handle the potential error is to use additional resources to do so. Rust forces the handling of the error by the language design itself, and in cases where the check is unnecessary within the bounds of the function, the compiler will actually optimize the match function away entirely for you. When someone later changes that code such that the check is required again, it will already be there in Rust; whereas it can be missed in C++.
This is literally several zero cost abstractions. Second, zero cost abstractions refer primarily to memory footprint anyway. As already pointed out, Rust does not require any additional memory to represent an Option than it does a &int by itself. Literally zero cost even when you DO use it.
That's not what zero cost means.
Regarding traits and concepts - wasn't it the other way around?
Rust had traits from get go while C++ introduced concepts waaaaay later in 2020 or something like that?
Rust reading loocked good until i started reading lifetimes.
i would say rust "borrowed" these features..
Exactly!
So when will the scope end? And return it ?
Compilation time?
Awesome video
Rust is amazing ❤❤❤❤❤
That's why i prefer c++ over rust
0:30 That's false. RAII stands for Scope-Based Resource Management.
SBRM..?
are you okay
(It's a quote from Kate Gregory in one of her many C++ conference talks here on the tubes. But regardless of the reference, I would think most people who have dealt with RAII will get the joke and agree that RAII is a terrible name.)
@@MasterHigure Admittedly the acronym doesn't give the full scope of meaning.
@@anon_y_mousse Mostly it doesn't explain the meaning on its own. It's very cryptic.
hi
The biggest problem with Rust is the lack of Rust developets. We wanted to start a Rust project at work, but it's not feasable, because we simply lack developers who are familliar with Rust. We have a bunch of C++ developers, but they all shrug at the idea of working with Rust.
Hire better engineers lol
because crap syntax and crap³ logic 💩 after ear of rust, I returned to C++
@@chqara Shaddap nobody cares what ALF says LOL
@@chqara strong arguments, spoken like a true C++ developer :D
You could just check if the maxElement iterator was equal to numbers.end() to see if you can dereference or not. That's not a fair comparison ...
That check is semantically equivalent to the Match statement in Rust. The difference is that RUST recognizes the potential error and FORCES you to handle that case while C++ is more than happy to allow you to write it in the buggy way with no warning that you messed up. These little gotchas can be a lot more subtle than this, especially over a large enough codebase; hence the 70% statistic put out by Google, Microsoft and other big tech companies.
Rust generics are not a refinement of C++ templates. They are just glorified macros. C++ also has constexpr which is far more powerful for generic programming.
With rust you would need to use macros to get anything close to proper templates.
@@JG-nm9zk Rust templates are essentially just compile-time macros (instead of simple preprocessor macros). They don't allow you to do the kind of powerful metaprogamming you can do in C++ with templates, constexpr, consteval, etc.
Rust is gay
I prefer C++ then because you need sometimes using new/delete.
I don't think you really understood then. Rust implicitly does the new/delete for you. They are still there under the hood. You can force rust to drop something earlier than you would have normally by using scopes (or by calling drop which is basically the same as delete), but Rust simply ensures that you can't try and access something which either hasn't been created or hasn't been deleted yet.
Surprise surprise.. Bjarne is a genius
💛I had the pleasure of being in the same room with him and listening to what he said. There was a Fireside Chat at Morgan Stanley's Budapest office around 2019.
@@AdamFiregate That’s awesome. He is easily my personal favorite computer scientist of the modern era. I love his approach to problem solving and I believe he is an exceptional teacher. Love his books!
Lost me at 4:00 when you said a simple for loop to find the max value is less readable than using C++'s insane iterators... to each their own i guess
What's so insane about them? The 'max_element' example looks very functional easy to read to me. I guess there are very ugly edge cases? Generally I prefer iterators over raw for loops in any language. Most of the time I declare a counter 'i', then get the i-th element from an array and never use i again. Might as well use the languages for-each construct. Less error prone too imo
@@NabekenProG87 Its a simple contrived exampled, in which yes, it is much simpler to read. In reality though most for loops are not this simple, and often you end up with a large chain of iterator functions thats as hard if not harder to reason than a simple loop.
@@NabekenProG87 The simple demo is fine, however C++'s iterators can get ugly quick
@hectormejia499 I agree 💯
@@hectormejia499 Ah, thx for the info. Never used 'functional' style in C++ all that much. I think it's quite usable in Rust and assumed C++ was similar, just more .begin .end
So basically C++ can do 90% of what Rust offers, with 10% of its pain.
No? Rust is way less painful
Stole is a negative wording. Inspired by would be more accurate.
I started learning Rust for a project of mine. The moment I realized it has incorporated a lot of stuff from C++ I dropped it like it was a ticking bomb. I am sticking with the old good C and Go for anything web related.
Lol on you
Reason?
I feel you about wanting to stay away from C++ but having done a good bit of rust (only for personal projects though), I haven't felt the presence of any of the things I don't like from C++.
Rust IS the new C. Where C++ frivolously added features "because we can!" Rust followed the disciplened approach of "because we should" and "perfection is achieved, when there is nothing left to remove".
@jazzycoderfor somebody making the bold claim that Rust devs are toxic you are hard at work all over the comments doing nothing but trolling...
That title and preview is misleading and arrogant.
Be humble and fair. And give credit to other languages.
Rust looks neat but at the same times is a brainfuck "wtf is this" kind of language. Especially when your new to it. The resource management of C++ is very elegant, the rust version is... just weird. Sure, it works, but the syntax is so unlike any other language that it just creates a steep learning curve right there to even grasp the concepts and make proper use of it. The C++ syntax for the same thing is just simpler to grasp. Still gonna learn and use rust but definitely not a fan of some of it's weird syntax.
Rust is following a trend from many other newer languages, like Go. Namely they try to follow English Subject-Verb-Object word order more closely in a lot of places.
In C you have:
"Integer A equals 5" (int a = 5;)
In Rust you have:
"Let A be an integer equal to 5" (let a: int = 5;)
And thanks to type inference you can eliminate redundant parts of that: "Let A equal 5" (let a = 5;)
Even C++ has started to adopt this way of doing things with lambdas and trailing return types for functions.
@@NovemberIGSnow Thank you, good to know! Not sure why you even post it though, it's not relevant to any of what i said, is it?
@@NovemberIGSnow
The order of variable declarations in C/C++ dates back to the 70s. Back then, C was a high-level assembler that worked with blocks of memory for which names were given. Moreover, in the first versions of C (before the C11 standard), it was necessary to define variables at the beginning of the code block. In essence, the description of the memory structure was primary, and the label of this memory was secondary. C++ inherited this.
And for modern languages that were already designed taking into account automatic type inference at runtime or at compilation stage, type indication is optional. In this case, the name of the variable, as a certain algebraic entity, comes first. And the type indication should be considered as a kind of restriction, which in most languages (including C++) is written through “:”
@@markg5891Can you give an example? What's "very elegant" with resource management in C++ compared to Rust?
@@RustIsWinning Look at 1:31. The way that C++ is written, in a memory safe manner, is elegant. The EXACT same rust snippet is "wtf is that?" kind of code. Like instead of giving a normal readable "new object in this scope" (which the make_unique does), in rust you have something names a "box".... What is a "box"? Sure, if you get into the rust-slang that might be normal to you.
Now go a step further into borrowing. make_shared is quite intuitive and easy to grasp, try that with the way you "barrow" in rust. Sure, lots is just getting used to the difference in slang and then getting used to it's weird syntactic way of writing. But exactly those two don't particularly help rust. At least not for me.
I find C++ template system (used along with concepts) much more flexible and powerful than Rust generics + macros. In C++ you are able to iterate much faster through different implementations and when the dust has settled down you can define various concepts to "formalize" the interface, whereas in Rust you would need to strictly define the interface (traits) to even compile the code. Also C++ constexpr is much better than anything Rust has to offer. Rust macros are a language on their own and an expert only feature, whereas in C++ just putting a constexpr specifier on a function, nowadays, makes it compile-time executable in most cases.
Yup, Rust leads to fragile codebases, and barriers to refactoring design. I suspect it's why the Servo project failed. It wasn't even a super low level problem space, Servo wasn't as OS... and yet, it failed.
I don't agree. Due to the aggressive inlining in Rust, and const propagation, without constexpr, a lot of things will be calculated at the compilation stage. But for complex cases, macros are still better. For example, it is possible to call a third-party solver from a macro and perform complex calculations which are inaccessible to the compiler.
@@cyberpunkspike The 2nd 🤡 arrived just to talk sht about Rust haha 🤣
@@cyberpunkspike Servo is in active development right now? My earliest rust code is already five years old and has not required any updates since deployment, and the speed of development and refactoring in Rust are faster than in C++, not slower.
The only real drawbacks are the compile times, and the learning curve. New programmers can make "useful" code in C++ faster than they can in Rust, but the difference in soundness between the two pieces of work will be night and day. Given enough time, they will be more productive in Rust than in C++. The confidence in their code will be far higher as well. Potential memory issues will be segregated to "unsafe" blocks which will be flagged by your code review process for a more thorough look to verify the memory safety guarantees have been upheld.
That is before you even begin to tackle the C++ flavor problem, multi-threading safety, etc.
Rust is nice, but that syntax ... bleah
The problem is C++ abstraction is not zero-cost. If you use virtual functions, you pay for extra vtable storage and lookup cost during runtime. Rust didn't offer anything like virtual functions imo.
When you use `dyn Trait` you’re using dynamic dispatch with a vtable. So this is definitely a feature offered by Rust
Rust does have something like virtual functions via trait objects and dynamic dispatch, though it's not exactly the same as C++. I believe C++ stores the pointer to the vtable as part of the object itself, whereas Rust stores the pointer to the vtable alongside the pointer to the object. I believe this is why Rust currently doesn't support casting from a trait object to another trait object, as Rust only knows the location of the vtable for the object's implementation of the first trait, not the second.
@@NeuwDk You are right, I am not very familiar with dyn trait, I was thinking about impl trait, which is more like CRTP in C++, guess dyn trait is equivalent to virtual functions and impl trait is eq to CRTP.
@@xiahualiu No, your concept of "zero-cost abstraction" is wrong, and your comparison actually does not make sense in the first place.
1) As you said, Rust does not provided "dynamic polymorphism via OOP". Therefore Rust has nothing to compare against C++'s virtual functions. End of story here; zero OOP support in Rust cannot be used against whether C++ really adheres to zero-cost abstraction or not in any way. Of course, Rust provides other means to achieve dynamic dispatching, but then you also have to compare that against C++'s dynamic dispatching mechanism. A whole different topic.
2) Zero-cost abstraction, or to be more rigorously speaking "zero-OVERHEAD abstraction", roughly means "What you do use, you couldn't hand code any better" as stated in the video 03:37. If you think virtual function in C++ is not zero-cost/zero-overhead, then you have to show that dynamic dispatching via OOP can be implemented cheaper than what C++ has right now, a vtable implementation. When Java was the New Kid on the Block, there were many discussions about this. Can we do dynamic polymorphism via OOP without vtable? If so, is it better? You can look up those discussions.
3) There do exist few infamous cases where you can make a reasonable argument that C++'s zero-cost/zero-overhead abstraction breaks down at some special cases. But it is not done how you stated in the OP. What you wrote is plainly wrong.
To be clear, I meant std::variant & std::visit in 1).
It is a valid discussion to figure out what is the best way to achieve dynamic dispatching; is it by dynamic polymorphism via OOP(virtual functions)? by static polymorphism(CRTP)? by dynamic dispatching(variant & visit)? It, however, is a discussion about design choices between different approaches, and has nothing to do with what approach is zero-cost/zero-overhead abstraction or not.
template system in c++ is a fucking nightmare. in c you have the macro system which will pre process your files. It's a pain in the ass to begin with because it's a simple "find and replace" program. But you can save the source code output after the pre processing and have a look at it. With c++ on the other hand, after the preprocessing step it will do the template resolution by changing your source code with whatever the template evaluates to. You'll never be able to see the source code after the templates have been applied. So when you get a compilation error in c++, it will point to to errors referencing that intermediary source that you have no access to. Fuck c++...
And fuck cmake as well
why rust don't have oop, especially inheritance?
Because rust is based
@@QuickNETTech I mean just is actually leans towrads oop quite a bit, just without the inheritance, which I think is better
It was a conscious design decision. Similar to that, you neither have inheritance in Go.
Inheritance and all it's subsequent worms are what OOP is to most people it seems, I'm glad Rust doesn't have them. I might maybe possibly forgive single inheritance but anything more I despise lol
I mean, technically Rust _does_ have a form of inheritance: interface inheritance via traits. By implementing a trait on a type, you are inheriting the public interface defined in the trait which lets you refer to that type as the trait alone, either statically via generics and monomorphisation, or dynamically via trait objects and dynamic dispatch. What Rust lacks is _data_ inheritance, where you can have a type inherit some _data_ defined in another abstract type. This was a conscious design choice, as, for some reason, data inheritance is typically what most beginner developers reach for first when trying to write some abstraction over some code, which causes innumerable problems later on when you suddenly need to change what data is included in the abstract type when trying to extend it with a new concrete type, breaking several other concrete types in the process. By only offering interface inheritance, Rust forces each and every concrete type to solely worry about its own data, which lets you change the data in one type without completely breaking other types.
Given that Rust was started in 2006, and C++ concepts came out in 2020, I'm going on a hunch to say that C++ stole Rust for point #3 😆
(Okok, C++ had templating, Rust made it better with traits, and then C++ stole traits to make Concepts)
No, your hunch is not correct. You can find earlier researches about "C++ concepts" or other similar constructs for different programming languages before Rust's introduction of Traits.(*) The original concept(no pun intended), which got implemented as C++ Concepts/Rust Traits/Swift Protocols, is NOT invented by neither C++ nor Rust nor Swift. It was proposed in the '80s, and first implemented by Haskell people. Then, it has researched, and its implementation has evolved through a very long time until it landed on C++, D, Rust, Swift, and others.
(*) For example,
Douglas Gregor, Jeremiah Willcock, and Andrew Lumsdaine, "Concepts for the C++0x standard library: approach", January 2006.
Rust was first made public in 2015, regardless of when the initial development was being worked on. C++ had concepts in Boost before 2006. If you want to argue that it wasn't standard, then go for it, but it's an irrelevant argument because the best part of the ecosystem for C++ is that so many libraries exist to allow you to accomplish tasks without waiting years for the standard to be updated.
you speak like chat gpt
You'd need to be more specific really.
let rust_new_feature = &cpp_best_feature;
Rust is not performant, because safety is its highest and sole design priority.
It is insanely fast and being safe doesn't make it slower. Actually, being safe makes it faster sometimes because you know 2 pointers don't overlap and you can do cache optimizations
@@svenyboyyt2304 We know you're lying when you claim it doesn't have any performance tradeoff.
@@svenyboyyt2304 It does make it slower, maybe it's worth it and it's performant enough, but it certainly has a cost.
not something to be proud of euhehuuuhe