Rust: When C Code Isn't Enough

When companies have gigantic code libraries written in C and filled with technical debt, they look to Rust to save them.
Points of reference:
martin.ankerl.com/2019/04/01/...
• "Whoops! I Rewrote it ...
/ @noboilerplate
github.com/motion-canvas
#programming #code #software

[@orbital1337]

Ehhh the reason why `std::unordered_map` is slower than Abseil's flat hash map is because it makes certain guarantees that the Abseil hash map doesn't make. There is no one-size fits all solution for containers unfortunately, only trade-offs. If you have really strict performance demands, you're going to have to find an implementation that makes the right trade-offs for your application.

[@Erryjet]

At least someone who really understand... this video is quite pointeless

[@AlFredo-sx2yy]

@@Erryjet ikr... this video was basically comparing the result of using completely different implementations of a hashmap, and not the difference between the languages. I also love how at first he said that the C program was easier to write because you had to tell the Rust compiler exactly what you wanted, and then at the end he says that all of the examples he's show somehow prove the rapidity of development in rust and i cant help but be completely baffled at the pointlessness of this video.

[@user-nw8pp1cy8q]

I would say, std::unordered_map optimized for very-very rare scenario. Open addressed hashmaps are better suited for the main purpose of hash map: associative arrays.

[@morglod]

too smart note for video about rust

[@groekanne7765]

A professor of mine also remarked in a recent C++ lecture how he was wrong in the past for using vectors for everything, which would cause hiccups in certain scenarios. Learning the differences and usecases for all containers is tedious, but rewarding.

[@Speykious]

The first example is great to illustrate in what way Rust forces you to get things right, but in reality this is something only a beginner would likely have a problem with. Once you get used to enough Rust (use it for two weeks or something), you pick up certain patterns, such as using &str (string slice) anywhere you need to use a string, unless in specific cases where you need to own one, for instance when initializing a struct. And in fact, using &str instead of String in this case makes it _actually_ equivalent to the C version where a char* was used (almost, since Rust works with utf8-checked string slices which have a length instead of zero-terminated strings, but that's just a detail).

[@CodeAhead]

Yeah great point, another commenter said something similar and I agree. Definitely most prevalent among the beginner / average programmer, or even an experienced programmer who is just a beginner at Rust. Also I did not know that about Rust string slices vs. C char pointers. Thank you for sharing!

[@Speykious]

@@CodeAhead You're welcome! :)

[@jongeduard]

Well, that detail, having UTF-8 by default in a programming language, is a really great one. And it's one of those things in which the language does not only do a greater job than C and C++, but also compared to some higher level languages like Java and C#, where UTF-8 isn't the default either (those languages use Unicode UTF-16 by default in memory, UTF-8 is only the default for things like file IO operations).

[@henriquemuccilloschumacher542]

@@jongeduard well most Windows and Mac OS X APIs use UTF-16 unicode internally, possibly forcing a conversion from UTF-8 to UTF-16 when calling those with these strings, that's also why QT choiced QString's implementation to use UTF-16 strings, but yeah it would be cool if they had native UTF-8 support , i saw some people talking about windows having new UTF-8 support but from what i searched it seems like that supports is mostly converting your UTF-8 string to UTF-16 which is still slower

[@mghost4416]

utf8 is the encoding of the internet and the future though

[@BGFutureBG]

"Rust is faster, because I'm using a third party component that is faster" Don't get me wrong, I get your point and the first example is pretty good, but the second one doesn't prove any point. C++'s implementation of the STL (or other stdlibs) is at most *suggested* by the standard committee, never implemented. The compiler / environment developers can choose what algorithms to actually use to implement them. I'm certain there is C++ libs that use Abseil's hashmap implementation for std::unordered_map. Also, C++ is not dying nor obsolete, since very useful revisions and redesigns are happening (c++17, c++20, c++23, ...)

[@ssokolow]

There are basically two points that you seem to be missing, both relating to composability: 1. Rust's strong encapsulation guarantees at the API level and unwillingness to rush into having a stable ABI mean that the Rust standard library can and has already had its stuff replaced with faster implementations, while C++ is stuck with slow implementations of various things that can't be upgraded without ABI breaks. (See "The Day The Standard Library Died" by cor3ntin, for example.) 2. As Bryan Cantrill says in the segment at 40:53 in "Is It Time to Rewrite the Operating System in Rust?", those guarantees make people more willing to engage in more aggressive optimizations. He's talking in the context of C, but C++'s decisions to remain so close to C for FFI compatibility, and the resultant memory unsafety, mean that it has similar problems. (eg. I've heard various examples of developers adopting "when in doubt, make a copy" policies around std::string and std::string_view in C++ for lack of the guarantees Rust's borrow checker provides surrounding string slices.) To quote the most important part of that Bryan Cantill bit I mentioned: "And it'd be easy to be like "Well, that's just B-Trees! ...not AVL trees." Yeah, but... the reason I could use a B-Tree and not an AVL tree, is because of that composability of Rust." "A B-Tree in C is gnarly. A B-Tree is just... I mean talk about intrusive. It's VERY intrusive. It's very kind of up in everything's underwear. And someone, of course, on the Internet's like "Well, you should go to use *this* B-Tree implementation." You look at the B-Tree implementation and are like "This is *rocky*! And if there's a memory corruption issue in here, I do not want to have to go find it." "I would still use an AVL tree in C even though I know I'm giving up some small amount of performance, but in Rust, I get to use a B-Tree." Rust isn't just about memory safety, it's about a pervasive effort to ensure that you only need to reason locally about code's behaviour.

[@BGFutureBG]

@@ssokolow Thanks for taking the time to elaborate. That's a point I can get behind. Wish it was made in the video

[@adamsoft7831]

​@@BGFutureBG Chandler Carruth has a number of talks at CppCon on KZbin that discuss the problems with the stdlib in C++. The APIs themselves require certain implementation details that are incompatible with the optimizations seen in the abseil flat hash map and Rust. A vendor cannot use this in their C++ standard library while also being compliant. That said, abseil is public, so it's not like you can't get the thing in C++. It's just a shame that the default option in C++ is often not very good. I'm a C++ Dev that has never used Rust, just annoyed by the language being unexpectedly slow for even simple tasks at times.

[@Wielorybkek]

It's actually first video about Rust I watched that actually convinced me that spending my time fighting the compiler could be worth it.

[@ariseyhun2085]

You'll come to realise that it no longer becomes fighting the compiler, it truly starts becoming a like a peer programmer helping you out always making sure you write safe code

[@wumwum42]

You have the choice to fight with the compiler or with the code docs, server errors and clients. Do you want to fight against one big army now or 1000s of small ambushes in the next 5 years?

[@nextlifeonearth]

@@wumwum42 Mostly this. You will learn to write compiling code faster on the first try or in not that much time. Languages like C will still compile if the program is incorrect and interpreted languages don't have that check at all and you **will** get unforeseen runtime errors in production. Unit tests can only catch these bugs if you make one that tests for that bug for each function. rustc does this before it compiles your tests. It's so much faster in that sense, even python can't hold a candle to this. How fast can you make that application? For python that may be faster than rust in general, by maybe a factor 2. How fast can you make it correctly? Rust will certainly win this one with a far bigger margin.

[@jdiehl2236]

It's a silly thing to do considering the Rust compiler always wins the fight.

[@Wielorybkek]

@@jdiehl2236 plot twist, I still don't code in Rust and don't plan to.

[@Speykious]

I'm not sure I dig this argument of Rust having better defaults as an explanation to why it is faster. In this specific case it is, but in others it can be different. I remember being unable to match some very simple Go program's performance and having to dig into Google's baked-in implementations to see what they were doing differently from Rust's std library. And at the end of the day I didn't manage to do it still. Sometimes it will be faster, sometimes it won't. However, the one advantage that Rust has regarding speed is zero-cost abstractions, and especially its very well optimized iterators which compile down to for loops and if statements.

[@Speykious]

@@jh29a I'm one of his patrons lol, but it wasn't copied, I just remember he said that and find that it is the best way to explain why iterators are fast xd

[@mattpattok3837]

Both examples of when coding can be hard seem to just be skill issues. In the Rust example, one would only write that code if they didn’t know how Rust memory management works. In the C example, one would only use those hash implementations if they didn’t know how their libraries worked. In either case there’s a steep learning curve; Rust is hard to learn and get used to, and a bad library is hard to understand. Difficulty to develop something is usually a function of developer skill and understanding of the codebase. Although on the subject of libraries, that comparison can fall apart depending on the libraries, and one would be ill advised to assume that Rust’s standard library will always be faster than an external library. In general, I don’t think claiming that Rust is faster than C is a great strategy. At the language level, C is still faster, and any algorithm that can be implemented in Rust can be implemented in C. Performance is part of Rust’s appeal, but its main selling point is memory management. Rust is a bit slower than C, but it’s still faster than most languages and in return you have guaranteed memory safety.

[@CodeAhead]

Interesting, that is very true. Thank you for sharing this, these are great points. To your point I would say that although you could do anything in C that you could in Rust, if memory safety is an issue it would probably be much faster (depending on the content and size of the project) to do it in Rust. If not an issue, definitely C would be the easier and faster (both in performance and productivity) choice. I should have been more clear about this in the video. Thanks again

[@TheCocoaDaddy]

I agree with your comments. This video felt more "pro-Rust" to me than an actual comparison. I mean look at the title of the video. Your point about skills is spot on. I'm very interested in learning more about Rust and I think it's fantastic, but I also think it's critical to keep comparisons like this as objective as possible to avoid sounding "fanboy-ish".

[@ssokolow]

Rust is a bit slower than C *on the benchmarks game*. Real-world situations keep showing Rust implementations to be faster because teams are willing to engage in more aggressive optimizations and are able to reuse more code written by skilled third parties. Listen to the segment of Bryan Cantrill's "Is It Time to Rewrite the Operating System in Rust?" at 40:53. The key part is this: "And it'd be easy to be like "Well, that's just B-Trees! ...not AVL trees." Yeah, but... the reason I could use a B-Tree and not an AVL tree, is because of that composability of Rust." "A B-Tree in C is gnarly. A B-Tree is just... I mean talk about intrusive. It's VERY intrusive. It's very kind of up in everything's underwear. And someone, of course, on the Internet's like "Well, you should go to use *this* B-Tree implementation." You look at the B-Tree implementation and are like "This is *rocky*! And if there's a memory corruption issue in here, I do not want to have to go find it." "I would still use an AVL tree in C even though I know I'm giving up some small amount of performance, but in Rust, I get to use a B-Tree."

[@TheCocoaDaddy]

@@ssokolow You make some great points, but they really point out @mattpattok3837's point. Those are "skills" issues. I would argue in favor of Rust because there just aren't as many people as "skilled" in C as there are in other languages, these days. "gnarly" programming can be a desirable challenge to some and something to completely avoid to others. Hence the interest in using third party libraries for so many things, these days. With that being stated, I certainly do understand the productivity arguments. One could argue programming in Rust can be far more productive because you're not spending as much time focusing on as many programming details, as you would have to if programming in C.

[@ssokolow]

@@TheCocoaDaddy Skill does play a part but empirical evidence seems to show that it becomes exponentially more difficult for humans working in groups to write correct C or C++ as group and project size increase. Personally, I'd see it less as "not enough skilled coders" and more as "not enough reckless coders".

[@NostraDavid2]

First video, and it's already a banger! Good pacing, clear voice, good supporting visuals. Nice!

[@CodeAhead]

Thanks so much!!

[@mailman7528]

Wow my youtube was autoplaying in the background and then this video came on! Super interesting and loved it! Love these type of coding videos that tell a story/have a goal or objective in them and also show/teach you something about the code! Please keep it up 👍

[@CodeAhead]

Thank you!!

[@1495978707]

4:40 The compiler gets angry with you if a variable is marked mut but isn’t changed, so unless the person writing the code is being purposefully deceptive, you can be sure that it will be changed. And when you try to compile the code yourself, it will give the same warning to you if it doesn’t need to be mut

[@badcalculon]

The compiler will get angry if no codepath changes the variable. It still might not change, it might not even be a common path

[@mattiamarchese6316]

Well, also in C/C++ you can specify a reference is const to be sure it won't be modified, but in this video since they want to prove Rust better they don't tell you that you can be sure a reference doesn't get touched.

[@Speykious]

@@mattiamarchese6316 C++ doesn't have interior immutability by default. Heck, most programming languages today don't have general immutability by default, it's a very recent shift in programming language design.

[@mattiamarchese6316]

@@Speykious for sure, as much as Rust doesn't have general mutability by default. It's just a choice, but if you want to make something immutable in C++ you just have to use const, what's wrong with this?

[@IndellableHatesHandles]

​@@mattiamarchese6316I generally use constant arguments more than mutable arguments. It gets quite annoying to incessantly type "const" everywhere. Not only do I type it several times per hour, but it's also two characters longer than mut. This doesn't sound like much, but I definitely prefer default immutability.

[@HotWings9001]

Wow, great video. I'm stunned it's the first video on your channel. Very informative and very well presented. That's it, tomorrow I'm starting a project to learn Rust (this time I mean it :D) Subscribed, obviously.

[@CodeAhead]

Thank you so much!!!! Glad you enjoyed :)

[@rondYT]

How did the project go?

[@krazymeanie]

Yeah there's clearly slot of inspiration from No Boilerplate's and Fireship's KZbin channel (which is a good thing BTW) No Boilerplate - youtube.com/@NoBoilerplate Fireship - youtube.com/@Fireship

[@bagel7860]

I think you gave an unfair example for c/c++. Though yes variables are mutable by default the const keyword would have fixed the problem of not knowing if the input is modified or not. I believe that it’s just easier to write bad c/c++

[@victotronics]

Agree that const solves many things in C++. Still, there are problems with lifetimes that the compiler doesn't even warn about that can give anwhere from wrong result to segfaults / other memory errors. I hear that Rust has solved that sort of thing. I need to learn about it.

[@darioabbece3948]

I do think rust can be faster than C because the borrow checking and the strictness of the language allows the processor to impove branch prediction and reduce overhead due to pointless re-checking and execution duplication of instruction

[@localboxcrox]

i was literally thinking the same. disappointed that no one else pointed this out.

[@corinnarust]

that's true WARNING: I'm a noob trying to explain complex things, there's a lot of errors and ambiguities in the explanation below. Rust uses RW-Lock pattern (multiple immutable references, single mutable reference) With this, you can assume a &mut will always be pointing to a different piece of data By this knowledge, Rust compiles mutable references equivalently to C++'s (maybe C too?) *restricted ptr These kind of pointers lead to memory optimizations in the binary, since compiler is able to inline values That's why multiple mutable references, even in single-thread, is undefined behavior in Rust

[@CodeAhead]

This is incredibly interesting, thanks for sharing. I'd like to maybe do a video on this (after doing lots more research on it). Maybe not but anyway thanks for mentioning this. Quite interesting

[@rayk6562]

Don’t you lose any advantage you gained because of the reference counting and branching needed to skip freeing the result?

[@angeldude101]

​@@rayk6562 Runtime reference counting is opt-in, so unless you expertly specify that your data has shared ownership, runtime reference counting will be completely absent from your binary. Compile-time reference counting you could argue is what the Rust compiler does, but it doesn't have a runtime cost.

[@eddiebreeg3885]

In the first example, the Rust code is equivalent line by line to the C code, the only reason you'd have issues writing is if you simply don't know the language. The same would then be applicable to C: if you've never used printf before, it's likely going to take you some time to figure it out. In the divide example, again: The rust code is basically equivalent to the C code, because in C you would mark the pointer as const if the function doesn't need to write to it. It's a convention that I have always seen used everywhere, so it isn't really that ambiguous. As for the return type, if you really wanted to make that clear, a simple typedef would allow you to change the int into something more explicit. As for the std::unordered_map, you can provide your own hash class to make it faster. I have seen benchmarks in which C++ absolutely crushes Rust, depending on the provided hash function. That said, the choice of said hash function is still up to the programmer, so the code will be a bit harder to write. Generally speaking I would say C does indeed require more time to write an equivalent amount of code, simply because you have to do a lot of work yourself. As for C++, I'm not convinced this is the case. By the way, C++ is faaaaaar from being in the same state as Cobol, it is still an actively developed langage, and is to this day still very widely used in the software industry, unlike Cobol which you will only encounter in very specific codebases, purely for legacy reasons. Take a look at job offerings for C++, Rust, and Cobol, I'm pretty certain the first one will give you way more results than the other two.

[@Erryjet]

Thanks god, someone pin this guy

[@danielhalachev4714]

Finally someone with a balanced opinion and not a C++ or Rust fanboy, blinded by their love for a language.

[@mp-fv2vi]

Very nice. Last weekend I started learning some rust - and now I've been inspired to get back to it again this weekend!

[@VivekYadav-ds8oz]

While yes Rust's default HashMap implementation is faster than C++'s, Rust's default hashing implementation is much slower than C++ (SipHash, which is DoS-resistant, but as a consequence much slower). Is changing the Hasher possible? Yes, infact it is very easy and is directly possible by passing it to the HashMap, but since we're comparing defaults, it's important to remember it's not all green the other side. In fact, slower hashing has often caused my Rust's HashMap to be slower than the C++'s one.

[@HennLoveGibson]

3:40 In bigger coding projects you should always specify function parameters as they are intended to be used. For example making param1 in your div() function a pointer to a constant value. int div(const int *param1, ...) if it is read-only

[@SapphireKR]

Pretty cool video, you deserve way more subs dude!

[@MadpolygonDEV]

great video, although im confused about the arguments and examples. Regarding the pointer passing and the idea of not knowing if the pointer is supposed to be operated on etc... You could pass that pointer as a const signaling that its read-only, immediately giving the reader an idea of what it is. Also the param names are poorly named too maybe. I think the examples you showed are mostly due to "bad code" practices than C C++ vs rust. About two sum, I would also argue that its not a C C++ limitation either. I personally think rust structure of writing code is a bit confusing, granted it may be due to me being new to it or being used to C.

[@CodeAhead]

Great points, thank you for sharing this. Everything you are saying is certainly true. With good practices and smart implementations the differences between C and Rust performance and readability are probably very small. I guess I was really just trying to show that while this is the case, C doesn't try nearly as hard as Rust to lead you towards good practices and smart implementations. That said I totally get what you are saying about Rust structure or syntax being confusing, I felt the same way for the longest time and still think that sometimes. Something about the minimalism of C is so refreshing, even if it can lead to unchecked memory vulnerabilities. Conversely, the Rust website says that, "We do not prize expressiveness, minimalism or elegance above other goals. These are desirable but subordinate goals."

[@PacificBird]

The thing is, the C code would let you write and compile it. The Rust Compiler simply doesn't let you work with data ambiguously. If it can't understand exactly what you're trying to do, you don't get to compile it!

[@caedenw]

@@PacificBird You can always write a linting rule for this specific case.

[@chrishusky1464]

when you explained how in C (and C++) it's more difficult to know what a function does exactly, it is true, sometimes. C programmers learn how to make it more clear. For instance, name the parameter of a function so that it can explain what it does (for instance, errCode), or use the modern intellisense and detail every parameter and return of the function with a comment that will then show up in the IntelliSense. Or even mark a parameter or a function as const. These are all things that most C programmers do. But I get it. Also, in C you could solve the first problem with either marking the parameter as const or making it a refference, then you wouldn't have the change the actual function call, and you don't have to care about it

[@aheendwhz1]

Is there some type of comment/docblock structure that is recognised by Intellisense for C? I'd love to know. Also, I'd be interested in static code analysers to read these docblocks and assert if they have been respected in the code. I come from the PHP world, where docblock comments are standardised by the PSR-5 standard and Psalm is a static code analyser that gives you a strong type system similar to TypeScript or Rust. I'd love to know if there is something similar for C.

[@chrishusky1464]

@@aheendwhz1 I can't say exactly for C since I'm a C++ dev, but I know there is something like that. I know that if you put a comment above a function or variable, that comment will be seen in the intellisense. And I think that if you put in @param parameterName and some text, it will display that text as the description of the parameter you specified. And @return should specify what the functions returns

[@CodeAhead]

Very true. I intentionally wrote both examples to have basically as much bad practice as possible to try and highlight that the defaults in Rust are forced to be more clear than in C (at least in my opinion, though you could of course argue otherwise). But yeah like you said definitely with good documentation, variable naming, etc the clarity is not really an issue, at least as much as I made it out to be. Thanks for pointing this out. Also I could be wrong but I believe that in C you cannot pass a variable as reference, only in C++. Though again I could be wrong about this. But if that is the case and you can only pass pointers I would also still feel that Rust's implementation of const pointers / references is better since it assumes immutable by default. Anyway thank you again for sharing this

[@KM-rw9cp]

​@@aheendwhz1en.m.wikipedia.org/wiki/Doxygen might be the one you're looking for.

[@teosfikas8289]

@@CodeAhead You are not wrong. There are no internal pointers in C like there are in CPP

[@uwuzote]

among all videos about rust and why is it that beautiful i find this one of the best ones! (sorry for bad english)

[@CodeAhead]

Thank you!!

[@etherweb6796]

KZbin recommended this video to me again, and watching it a second time just shows more of the flaws in logic: Twitter developers re-writing something in Rust faster than refactoring C code doesn't tell us anything about whether the C code was good, readable, or idiomatic - It could, but it is more likely just telling us that these particular devs didn't understand it as well as they understood Rust. Then the video switches to "well the default hashmap library in rust is faster" without discussing why that is so - hashing algorithms can be as specific or generic as you can make them, and it is all about tradeoffs - maybe "cody's random hashmap" library is actually better for a particular use case than the standard Rust hashmap, but there is a performance cost that is worth it in the long run - the only way you'd know is reading the code or the documentation to find out - which is the same thing regardless of whether you use Rust or C for your implementation.

[@Whatthetrash]

Fantastic video! Got here from KZbin recommendations. :)

[@CodeAhead]

Thanks, glad you enjoyed!

[@none_of_your_business]

Thanks for telling me about swiss tables. I added it to my C++ library bookmarks folder ;D

[@CodeAhead]

Of course! Glad to hear that

[@TWGuardian]

Excellent video, and something I didn't think of before: newer languages have more recent improvements to algorithms built into the standard library. What I think is a bit implicit though in the topic of 'consider Rust over C/C++ for longevity purposes', is a feature that C and C++ have that also harms it a bit: the guarantee of backwards compatibility with each new language release. This means that bad, old parts of the language still have to be included and maintained, rather than pruning bad or obsolete parts of the language and focusing development on better, newer paradigms. This is not the strategy of C and C++ because it would mean that each language revision would break compatibility with older language versions which would strain development. Newer languages like Rust do not have this problem of having to carry years worth of obsolete features, not least because said features have not (yet) had time to accumulate. This also helps with program development because one needn't sift through a dozen or so options to weed out bad practices that were rendered obsolete by language revisions.

[@swapode]

Backwards compatibility is actually something the people behind Rust take seriously and have a beautiful solution: Editions. We could launch a new version of Rust with breaking changes (say like Python 2 to 3) tomorrow - without breaking anything. Every cargo project knows what edition it's in and the compiler will treat them accordingly. Not only can you compile your ancient legacy code with the newest compiler version but you can combine different libraries written to completely different standards and the compiler will figure it out.

[@TWGuardian]

@@swapode That's a beautiful solution indeed, and another reason to love Rust!

[@marko-lazic]

Great video, subbed

[@J-Random-Luser]

I like this video, and I like Rust. I'm also a C programmer, and spend most of my time coding in C. That being said, I feel the example of the divide function is quite cherry picked (though I doubt it was intentional cherry picking). C gives us ways to give the caller information about intention through the use of qualifiers like *const*, and *restrict*, and (at least in code I write), it is not uncommon to have an "Error" structure that returns data, as well as an error code wrapped neatly in a structure. This explicitly tells the caller that the function returns an error, and it should be handled. Obviously, one of the main benefits of Rust is that it *forces* you to do all of these things-- it forces you to explain intention, but I feel like that part was left out since you did not mention that C does have ways to communicate intent to the programmer. Or maybe I just missed something in the video, I dunno. EDIT: Clarification.

[@angeldude101]

My understanding is that restrict is very rarely used in actual C code, to the point that it had a long-standing bug in LLVM that was only discovered when Rust started tagging nearly every function with it.

[@ItsCOMMANDer_]

​@@angeldude101tbh, in the ehader file for strings (string.h) in gcc, restrict is in nearly every parameter in string functions and can be a useful micro opimization for low level programming, especaly on micro controllers

[@onaecO]

Bro great stuff keep it up!, i'll like it all the videos to pump you 😉

[@AV_YOUTUBE_202X]

Very informative!

[@kevinyonan9666]

A compelling video but C still reigns supreme for me concerning bytecode interpreters.

[@faysoufox]

Nice video, looking forward to others like this

[@SimGunther]

Having the compiler be the sandbox as far as form creation (what memory handling strategy we need for the solution) is great only when you know exactly what the logic of the code is. Good old fashion debugging and sense making (ala Bret Victor interactive infographics) is still necessary for logic checking in the long run.

[@diadetediotedio6918]

?

[@ssokolow]

However, Rust's bigger strength is its type system in general. You can teach the compiler all sorts of new invariants to enforce. For example, the typestate pattern lets you teach it to check for correct traversal of state machines at compile time. (The Hyper HTTP library uses it so that things like "tried to set a header after the request body began streaming" are compile-time errors.) With C++, you need inefficient and verbose runtime checks to match that because, without a borrow checker, there's no compile-time way to prevent code from holding and using stale references if you implement the typestate pattern.

[@diadetediotedio6918]

@@ssokolow I don't really like do defend C++, but I would here for the sake of the reason and truth. In C++ you probably can express typestates (I have seen somes in Github using classes and templates), but in general I would say implementing them in Rust is way easier and safer because of the strictness of the language compared to C++.

[@ssokolow]

@@diadetediotedio6918 That's more or less what I intended to be saying. I've seen typestate implementations in C++ too, but the authors always make it clear that, without a borrow checker, it's possible to hold onto and use stale states or that they have the performance overhead of runtime safety checks.

[@cazz]

Nice video brother, keep it up!

[@DarxDev]

bruh usually if an input is getting modified in c it will be non-const or mutable. and if its not getting modified then it will be const. That divide function segment feels cap as hell, I've been working with c libraries and team projects for a while and with proper commenting and coding standards I never get theses issues of code ambiguity

[@CodeAhead]

That's fair. Though I would argue that Rust's implementations are better due to immutability by default rather than C's mutable by default. But definitely you could make it a pointer to a constant value. That segment spawned from my own difficulties writing a simple ext2 file system in C. Lots of library functions took non-const pointers and I never knew what they did with them until searching the web for a bit. But it could easily be due to backwards compatibility and age, and maybe most younger C libraries are more intuitive.

[@_M_643]

I don't know why KZbin keeps recommending me Rust videos when I prefer C/C++ more. Guess I'll have to manually start telling KZbin to not recommend Rust to me.

[@diadetediotedio6918]

Maybe this is an oportunity for you to learn Rust now

[@_M_643]

@@diadetediotedio6918 Tried it before and definitely prefer C/C++ over it.

[@diadetediotedio6918]

@@_M_643 Interesting, why that's the case? I'm trully curious

[@_M_643]

@DiadeTedio Tedio Well, I decided to check it out, knowing that it has a bit of a cult fanbase, which initially drove me off. It was a painful experience because the compiler wants you to do things in a specific way, and anything different than that is an error. Basically, it doesn't allow me to do things that C or C++ would normally allow. I don't care about memory safety if I can't do things my own way.

[@diadetediotedio6918]

​@@_M_643 I would say C++ is much more "cultish" than Rust by a larger ammount, but this is just myself talking, because I'm in contact with the C++ community longer than I'm in contact with the Rust community, but ok. For the next, have you tried Go? It is safer than C or C++, relatively fast and has some of this "freedom" to do different things, maybe it would be good for you to learn hard some other languages, just for fun and because learning is almost all good. Maybe you just don't like Rust, but if you recognize the need of the language when safety a concern, that's fine!

[@alexandermandt2117]

So, I might be wrong, but I believe the statement that with every ‘greet(name.clone())’ call you use more memory is technically false. Actually, when you call the greet function, the cloned name value is given to the greet function. Thereby, the greet function becomes the owner of the name clone. Once the greet() function has finished executing and returns to main(), the name clone gets destroyed due to how rust manages memory. Therefore, you use some extraa memory when you clone name. But this code frees this memory before you clone again. You still get a slowdown, because you always copy,but you do not use more memory with more greet calls, as Rust automatically deallocates the name clone once the function greet() returns.

[@CodeAhead]

You are correct, this was a mistake I made in the video. I apologize for that, and thank you for pointing this out!

[@alexandermandt2117]

@@CodeAhead thx for reading comments and interacting with your usebase. And no need to apologize for that. The essential message is still correct.

[@xcoder1122]

The speed of Rust depends a lot on what your code actually does. I have a small test benchmark that performs fractal calculations, no fancy objects or structures are involved except arrays, and this code runs 10% faster in Rust than in C, who would have expected that? However, if I modify the benchmark to compute many more fractal values that all need to be held in memory, the Rust code is suddenly 20% slower than the C code. Sure, in the end it's all LLVM, but there are certain operations that are faster in LLVM than others, and certain combination patterns cause more code than others (e.g. because of extra checks or more cleanup at the end of a function). Rust is neither guaranteed faster nor guaranteed slower, it all depends on what your code actually does and how your code does it, and how well the compiler can optimize away the things that would otherwise make Rust slower, or how much the compiler can benefit from making assumptions about data or code flow that it can only make in Rust but not in C, where those assumptions end up leading to better CPU code. Since Rust is much more complicated under the hood than C, the final speed will always be a kind of gamble ("Oh, if I change this, my code will be 60% faster... I didn't expect that"), whereas speed in C is predictable most of the time ("It was clear that this will be faster than that"), but that still doesn't mean that C will always end up with the best performance, as C simply provides less meta-information for compilers to work with, so compilers can't always figure out the best optimization path, as they simply have less understanding of what's really going on, or they have to be prepared to deal with exceptional cases, which may be guaranteed not to happen with comparable Rust code. The takeaway is that for a way safer and way better typed language, Rust is often comparable fast, but in most cases it will still be slightly slower, so you are trading a tiny bit of speed for way more safety. My biggest grief with Rust is that I already disliked C++ just because it's syntax is so ugly but the syntax of Rust is even worse.

[@lepidoptera9337]

There is nothing unsafe about C. People simply don't know how to use it. I also doubt that Rust can beat properly optimized C code if the compiler optimizations are the same. It might not even be the code. Individual results might have something to do with cache hit/miss rates or pipelines rather than the actual code. Even LLVM can not optimize that since it's strongly data dependent.

[@xcoder1122]

​@@lepidoptera9337C is unsafe because its memory model is unsafe. Unless you use C11 atomics (which didn't even exist prior to 2011), C provides no guarantees about memory access at all. The problem is that every platform/CPU has its own memory rules and you would have to make sure to write C code that follows those rules but since those rules vary by platform/CPU, it's actually not truly possible to write C code that is guaranteed to work correctly on more than one platform. If it does, that's plain luck. Modern programming languages like Rust, Swift, Go and even Java and C# do define a memory model as part of the language that is valid for all platforms the language supports. It's up to the compiler/interpreter to ensure that this memory model works as defined by the language on the platform, no matter what is required to make that happen. The programmer doesn't have to adopt his code to any platform for those, the programmer can rely on what is defined in the language standard. Here's a very simple example: You have a global variable of type int, whose value is currently 0 and you change its value to 10 in thread A. 30 minutes later, the variable has never been touched ever since, you read the value of the variable on thread B, what will the value be? 10? Show me where the C standard makes that guarantee. Fact is: It doesn't. Prior to C11 C didn't even acknowledge the existence of multiple threads. But even without threads: You only have one thread, that runs on CPU 1 and you write a value, 30 minutes later the SAME thread runs on CPU 2 and reads the value. Again, where does the C Standard guarantee that CPU 2 will see the value that CPU 1 has written? It doesn't, because C does not acknowledge the existence of systems with more than one CPU. And what applies to CPUs also applies to cores of a single CPU. Only when using atomic variables as defined by C11, there now is a memory model and you as programmer can even choose between 6 different memory models but for everything that is not atomic, nothing is defined. Without atomics, the way you think C works in fact only works if all your code is always running on a single thread only and your system only has one CPU core or if you are lucky and the CPU does make that guarantee in hardware; like x86 does most of the time but PPC, ARM, Alpha, RISC-V, etc. doesn't make those guarantees. That's why so much C code that worked flawless on x86 CPUs fore decades suddenly breaks when it has to run on other CPUs. The code was never correct in the first place but x86 is very forgiving and gives a lot of memory access and ordering guarantees that other CPUs don't. So you basically had C code, that was valid for x86 in particular but that doesn't make it universally valid, as there is no such thing as universally valid C code, because C leaves most definitions to the system, instead of defining it to the language. This is also true for plenty of other situations. E.g. what happens if a signed int overflows? Not defined in the C standard. What happens when you de-reference NULL? Not defined in the C standard. What happens when you shift a 32 bit integer right by 32? Not defined in the C standard. Of course, on every platform the behavior is defined but the definition varies by platform, that's why modern languages define it as part of the language. As for performance, I have a C code sample, that calculates a Mandelbrot set. It's as basic as this calculation can get (three for loops, an array of float values, some simple int and float calculations, one static function being called from within the main for loop). When I compile it with clang using -O3, the code runs slightly slower as when I take the code as is, convert it to Rust (which almost requires no adoption, except for the data types and the function definitions) and compile it with the Rust compiler. Reproducible on x86 and on ARM CPUs. If KZbin would allow external links, I'd show you the code and I take any bet, you cannot make the C code run faster than than the Rust code, as there is nothing you could optimize about that code and there is no better optimization than -O3.

[@xcoder1122]

​@@lepidoptera9337If I could post links here, I could show you a simple Mandelbrot calculation code that will run faster in Rust than in C and I bet that there is nothing you can do to make this code run faster in C, as this code is minimalistic and there is nothing you could optimize that the compiler cannot optimize 100 times better than you and still Rust always wins on x86 and ARM with both compilers set to maximum optimization. And C is unsafe because it does not define a memory model (only for atomics which only exists since 2011) and it also has tons of undefined behavior, where the C standard simply does not define what the outcome of an operation will be. This makes it very easy to port C to any platform but it also means that the same code will not behave the same on different platforms. Modern languages have a well defined memory model and well defined behavior and it is the task of the compiler to ensure this behavior on all supported platforms, no matter what is required to make that happen, so you can rely that the same code will produce the same results on any platform.

[@LinuxPlayer9]

Good video so I am subscribing

[@alzeNL]

Interesting video with interesting comments, thanks for the upload.

[@GoldenBeholden]

Appreciate the CC.

[@erik....]

Great, I was just about the rewrite the facebook backend and found this!

[@sdbadik]

Cool video! Very interesting!

[@CodeAhead]

Thank you!

[@cocacodes]

Very nice, may the yt algorithm recommend it more!

[@HyperFocusMarshmallow]

I can’t help but feel confused about “C < Rust”. If it’s speed we measure less time would be better right 😅. And if it’s meant as the English translation to “greater than” in some sense of general goodness or greatness well then that pun doesn’t work as well for “less than”. You kind of have to read it as “worse than” for the pun to work but that doesn’t really make a good pun with “

[@ElPikacupacabra]

There are no zero cost abstractions in programming. Rust encourages the use of more abstractions than C does. Hence Rust will always be on average slower. (Yes, when fine tuned all systems languages are equally fast with the same compiler backend.)

[@angeldude101]

-O It won't clean up every abstraction, but it will inline most basic method calls, yielding the same assembly as if you wrote the code in hand-optimized C. "Zero cost" means that you couldn't have written faster code manually, so it's more like "zero overhead."

[@ElPikacupacabra]

@@angeldude101 "You couldn't have written faster code manually" that does the SAME thing. Maybe... But the abstraction generalises the problem, hence it will never be the most efficient way of solving your particular one. Abstractions force you to think in general terms and code for a wider class of problems. The more you abstract away, the further you are from the optimum. That's what I'm trying to say here.

[@angeldude101]

@@ElPikacupacabra When in doubt, inspect the assembly output. The compiler is smarter than you probably think, especially with optimizations turned on.

[@Selicre]

If it compiles to the same thing, it's a zero-cost abstraction, so yes, they do exist. I don't see your point.

[@ElPikacupacabra]

@@Selicre The problem is that you won't be implementing the optimal solution, not that you cannot. That's because you over-abstract. For example, std::vector is not the optimal dynamic array implementation in all cases, but you wouldn't know that if you don't see the details relevant to your problem.

[@jedisct1]

Zig has entered the chat...

[@TehPwnerer]

Rust is completely memory safe? Challenge accepted

[@angeldude101]

_Safe_ Rust is memory safe. _Unsafe_ Rust is not memory safe, but if you can make sure that what unsafe code you have is sound, then you don't need to worry about any of the safe code.

[@AlFredo-sx2yy]

@@angeldude101 safe rust can leak, so the way the rust standard managed to make safe rust be memory safe is by... simply stating that leaking is considered to be safe despite the fact that it actually is not... damn, so much for safety i guess.

[@angeldude101]

@@AlFredo-sx2yy Memory leaks don't violate type safety, nor do they allow you to access arbitrary memory addresses. They can cause things to break if the program runs for long enough, but it takes enough effort to cause a memory leak (either explicitly calling Box::leak() or using RCs with interior mutability to make a cycle) that it was decided that it wouldn't be too hard to avoid in a long-running service. And then when it does break, it's usually just in the form of crashing, which while very undesirable, especially in the kernel or an embedded system, also isn't memory unsafe. I would like to hear why you claim that memory leaks are as unsafe as type system violations or data races.

[@AlFredo-sx2yy]

​@@angeldude101 if you leak on a memory arena / linear allocator of sorts, you're basically going to begin overwriting memory at some point, for example imagine a set of pages / arenas that the programmer has set up to contain a bunch of objects for whatever purpose (game engines and other visualization programs usually reserve space like this), if you now leak enough, you can have your program start writing data on whatever comes after your arena if there's no proper handling, even in safe rust, which means you have basically a buffer overflow. Simplest example i could come up with. Another example: since the heap is usually implemented as a set of memory arenas, if the OS had no protections in place, this would mean that you could potentially start accessing memory from a different program. This is not possible in modenr OSs because of the protection measures in place that prevent this sort of problems, but when you're running code in an embedded system, if you have a small arena for whatever purpose, you could theoretically come across this problem and start overwriting whatever is located in memory after your heap. All of these examples require a bad implementation of a memory arena, obviously... but the problem is that they are all possible to make in SAFE Rust.

[@SheelByTorn]

06:04 "compiling with g++" you should have used "clang++" not "g++" since by default it uses LLVM like rust, this is not the case for gcc/g++

[@CodeAhead]

Interesting, I will keep that in mind going forward. Thank you!!

[@phildem414]

This pickup would certainly benefit to get a series/parallel switch! Or a split 🤔 Or a tri sound

[@Iraxvii]

Great video. And the young thug picture you kept using made me laugh so hard for some reason

[@sepio_]

would be nice for the next video to see the performance and productivity comparison that doesn't involve 3rd party libraries

[@atlas569]

The audio is relatively low for youtube videos, and even at max settings, I still had some trouble understanding.

[@BogdanTheGeek]

@3:32 There is a very simple way to "say" that a function will only reference a pointer: int i_reference(const char *const string); // string is a constant pointer to constant data, aka. immutable int i_mutate(char *const string); // string is a constant pointer to variable data, aka. mutable. int i_am_unsafe_read_doc(char * str) // whoever wrote this, had no regard for safety, purge this from your codebase. All pointers are copied by default in C, because their size is 1 word, so the *const doesn't affect functionality, but shows intent.

[@kvelez]

Interesting, bring more.

[@MrAbrazildo]

4:20, C++ can return a string empty or with an error message too. But this approach is slow, because it needs to create the string. Faster is to do what C use to do: return an integer, with negative value in case of error. Then, if the user wants to see the error message, it can be fetch in an global array of errors. C can also return a null pointer, in case of success, and a valid pointer to an error message otherwise. But the int8 return is faster. 4:34, C++ can say if a parameter is const or not too. Your example doesn't beat C++ by any means. To be fair, there's 1 case: if they are int pointer and an int, there's a possible performance issue: pointer aliasing. It can be solved by copying the int to a local variable or by using some compiler-specific keyword, such as restrict, but this last solution is not standard yet. This is an annoyance Rust hasn't.

[@peter9477]

Using clone repeatedly as you pass each string to the greet() function isn't using more memory *each* time, because each instance is immediately dropped inside the function. But anyway as others have said only a Rust rookie would write it that way.

[@dylanmashini5700]

but it still has to allocate each time, which is the biggest overhead with memory

[@peter9477]

@@dylanmashini5700 Certainly. Nobody would say it was a good approach. I'm just noting that what was stated is technically incorrect, and not the reason it's a bad idea. (Edited to fix typo.)

[@CodeAhead]

Well said, thank you for correcting me. Apologies for the mistake in the video!

[@enderger5308]

In fact, the algorithm would probably use the same amount regardless due to memory paging. The string should fit in the same page as the original, so it theoretically would just be calling memadvise and not actually use a full allocation. It’s still slower, but isn’t as bad as it could be unless you’re unlucky enough to do this on a page boundary.

[@IndellableHatesHandles]

Passing by value looks a lot like a unique_ptr, except on the stack. Pretty neat.

[@Lupinicus1664]

Valuable content. It is refreshing to see modern programmers dealing with performance (in detail). When I started in 1980 coding in assembly efficiecy and performance were critical and that continued when languages like C came along. I think your content is important and this level of discussion important too. Do we think Rust is good for 50 years ?

[@billr3053]

It’s about time [modern programmers deal with efficiency]. Code has become so sloppy and cumbersome. I come from “old school” - assembler, Z80, 80386. High performance code is what was expected of me when I was consultant / programmer analyst - banking, credit card authorization, transaction processing. User-response time was critical. Transactions-per-second internally. Over the decades the solution was to throw more powerful hardware at it. Programmers continued to become lazy and sloppy - linear searches (like they just came out of computer-101, which they probably did).

[@JorgetePanete]

I think Rust can evolve well, I hope it or some other new language gets dependent types to make even better code

[@tabletopjam4894]

I wish there was a codecademy-esque place to learn rust, every place I look is like reading a big book and I don’t learn effectively that way

[@mymoomin0952]

try "rustlings". it's a series of simple exercises to solve that take you through basic rust stuff

[@dnullify100]

Look up rustlings. Installable exercises

[@nurhusni]

2:00 is there any explanation on why we need to clone it? what does it mean by "moved"?

[@F_Around_and_find_out]

Outside of the code writing I believe that Rust is great for teamwork because of the config file, the toml I think. Just type in whatever dependencies you need in there and cargo will do it all for you, all the correct pakages, the correct version of Rust you want and then cargo run, kinda like Python venv. So not only does Rust code is explicit and precise, but the way Rust manages itself is just so good, any team member with Rust installed can just take that toml file and run it, and they are set.

[@t.h.4823]

As far as I am concerned, you do not have to clone tha string over and over again. You can use &str (string slice) which basically creates a copy, however it deletes itself after the call, thus not overloading the memory, so the clone example is not right, imho.

[@evanleong8638]

I was gonna like the video but then I realized that CodeAhead is using the $5 Bugha microphone, so i retracted my like because my ears fell off, otherwise this was a good video I thoroughly enjoyed it

[@luckybutunlucky8937]

I've never worked at a tech job or done anything that wasn't for myself only. Meaning I don't care what language I programmed it in because even if the source code is different it'll all be compiled based on how you structure it. Yes the function implementations for a hash may be faster because of a different technique but if you really wanted a faster implementation without changing to Rust you could just make your own hash map and optimize it for your specific use cases.

[@torphedo6286]

hmm, this was very interesting. I do really like that it would force you to explicitly mark mutability. I may consider writing my future code in Rust...

[@antoniomontana351]

Informative, relaxing voice...

[@thebaconbreadful]

Hey, this is a really good video and I enjoyed it quite a bit to learn about your views. If you want to grow this channel you should be aware that sound quality is a major aspect of a good video. This is a point that could be improved.

[@CodeAhead]

Thanks, I appreciate the feedback a lot. Lots of people have said the same, and I honestly never thought this video would get so popular so I never cared about how bad the audio was lol. But now I am definitely considering upgrading my setup. Thanks again

[@thebaconbreadful]

@@CodeAhead You definitely have a skill for explaining things in a compelling matter and rust is a hot topic. Maybe you can capitalize on this hence you are in the early wave of creators adopting rust. edit: the sooner you get another video out the better. This way the algorithm might pick you up again.

[@mrvogti6542]

or u could use for example the "const" keyword in c in the 'divide' function

[@Salehalanazi-7]

Okay I'm officially convinced

[@Shnugs]

The only thing I can like Rust to is Bloodborn: frustrating as hell to initially pick up, but once you understand that it’s actively teaching you how to use it just by engaging, it’s so gratifying

[@JimStanfield-zo2pz]

You convinced me. Writing my server backend in rust. I was considering c.

[@NoBoilerplate]

When's the next video my dude? You've got everything here that makes a great channel, what are you currently passionate about? Tell us about it! 😄 (My only feedback, if I may, would be to use a better mic, don't buy one, just use your phone's microphone like I demo in my "how to sound great" video) Looking forward to seeing more!

[@CodeAhead]

Thank you, that means so much coming from the best! I will definitely follow that advice if I end up making another video. I was having a lot of trouble with my adsense account which was killing my motivation, but hopefully the situation can be resolved in the future. Until then I will learn as much as possible to have some material for the future! ;)

[@Victor-ym9fo]

Very good video.

[@HelloThere-xs8ss]

C is good for learning *how* things work.

[@HelloThere-xs8ss]

Rust simply makes work good. 🦀

[@KohuGaly]

Except, Rust is better at it. I learned more about how things work from reading rust docs to make my rust programs compile, than from debugging my UB-ridden C code. C leaves you with more misconceptions than facts, because it obfuscates stuff while pretending it doesn't.

[@HelloThere-xs8ss]

@@KohuGaly dude... It was light humor...

[@daviddickey9832]

12.6 ns wow that's crazy how fast that is

[@1InVader1]

In the 2nd C code example, whoever made that code should use const to denote when an argument in a function isn't changed. However, I do agree, that it's better in Rust to have a variable declared explicitly as mutable, instead of relying on a human to follow the C coding standard of using const whenever possible without error. Sometimes you really just forget and C doesn't raise an error for that (but maybe a warning?). There's also the fact that when using Lambdas in C++, the captures are constant by default, so you have to use the `mutable` keyword instead, which is the exact opposite of the existing standard of using const wherever possible. People say C++17. 20, 23 etc. come with great improvements, but honestly, it's getting weirder overall. Or there's std:forward, which finally lets you fix move semantics introduced in C++11 where std:move didn't always "move" your data as it implied, it just passed stuff as an rvalue ref, and then when you use it in a function argument, in the body of the function the rvalue ref becomes and lvalue object containing the rvalue ref, so you're invoking copy-constructors again, even though std:move itself was introduced specifically to reduce the amount of deep-copies. I could've just used a good old raw C pointer and simply reassign data pointers in the move constructor to move data. It's just 2 lines of code! But noooo, you're not supposed to use raw C pointers, those are scary and evil! While smart-pointers are a nice thing, all this bs could be avoided if people would just quit being plebs and learn proper pointer semantics and patterns, and then you don't have to spend years learning the weird nooks and crannies of the MASSIVE C++standard library. Again, I realize the issue here is that even though you know what you're doing, humans could just simply forget and C/C++ won't throw you an error for it, unless you use smart pointers. Iterators: god forbid you change the length of the container you're iterating on by inserting or removing, because that will wreck your iterator and get a runtime segmentation error. We're talking about the STL iterators, which are specifically designed to work with STL containers and the rest of the standard library, but actually they don't! This is trash! Again, I could use a classic loop with C pointer set-up and it would be both safer and faster for just 1 extra line of code! Modern C++ literally just introduces new points of failure and slower performance for the small, tiny payout of having slightly less boiler-plate code, but if you do actually use every modern C++ feature, then your code looks like Haskell and it's unreadable.

[@lepidoptera9337]

These attributes exist because the compiler can not know how you want to use a piece of memory... as a variable or as a constant. There are good reasons to store constants in a different area of the memory than the variables. C let's you chose that (and a lot more). Rust does not, as far as I understand. It makes educated guesses for you, which may or may not be correct.

[@oefzdegoeggl]

agree 100% on this. i ported a lot of code over from c++ to rust. sure, there is a learning curve and you have to learn a lot more than porting to some random plastic language like python, swift, kotlin, dart and so on, but it's worth it.

[@lepidoptera9337]

Porting from C++ to Python doesn't make any sense to begin with.

[@BeenYT]

"Segmentation fault (core dumped)" is the message c programmers fear the most

[@lepidoptera9337]

It is trivial to avoid that. If it happens to you, it's basically just a feedback from the compiler that you don't understand what you are doing. Nothing to fear. You just have to start learning.

[@Phantom-lr6cs]

segmentation fault came from OS not from c lang kid . it has nothing to do with c . its comes when some morons code and they don't know what they are doing XD

[@bluestaggo]

Rust is such a strict language, but in the end it is worth it!

[@gingeral253]

This video is convincing me to learn Rust.

[@wumwum42]

I remember a conference talk about c that ended with: "C is great, use something else." and with "if you want to use C, think about it, then use something else." I am a rust fan and was expecting the presenter to convince everyone to use C lol.

[@elzabethtatcher9570]

Looked to see more videos on this channel and was dissapointed to find none. Please shoot more about topics you are passionate about!

[@heitorheitorheitor8158]

What font are you using in the code? I loved it

[@CodeAhead]

I was using the Iosevka font, specifically the extended variant because I think it looks better than the regular one

[@TDG361]

I think we should be speaking more about the advantages and disadvantages of each programming language, and thus concluding which is better suited for which situations and why. Yes, C is old, not as friendly as Rust, and can be a headache at times, but it fulfills excellent its original purpose: writing operating systems. As with all technologies, we should know which one to use and when.😄

[@marcossidoruk8033]

C is much friendlier and easier to work with than Rust lol.

[@ItsCOMMANDer_]

Or for legacy systems (like 3ds)and micro controllers

[@simonfarre4907]

No way you brought up team, intentions and our own intentions and had an image of Young Thug. You sir, have earned a subscriber. Too few of us in this field.

The other reason why Rust can be faster than C is that some code using ton of pointers that would be risky to write in C is perfectly safe in Rust. I've seen C++ code copying a value multiple times just because it was safer than using a pointer or reference. The only time I saw such Rust code was because it was written by a beginner who wasn't thinking about it.

[@tawandagamedevs]

Graphics programming in rust is such a pain. Especially vulkan wrappers are not that good its just unsafe code under the hood.

[@JonitoFischer]

The fastest is C, C++ is bloated, even C is bloated when compared to Assembly. And you're talking about libraries...

[@KeinNiemand]

I prefer C#, but of course it's way slower due to having an intermidiate languate and using a garbage collector.

[@finmat95]

Mmmmmh...yea, it makes sense. Thank you.

[@kebman]

In Rust .... We Trust!

[@explodingonc2782]

I don't think there is any language compariable to C in my field, that is, directly manipulating hardware, like peripherals and registers. Not even C++. However in fields at a little higher level than that, C/C++ is definitely not the first thing I would consider. Normally I would put all hardware I/O operations into a dll written with C, and use Python or Rust to handle higher level operations.

[@miguelpereira934]

Super interesting video! I just started learning C in University and I'm already seeing some videos on Rust outperforming C/C++. We won't learn Rust but wil definetly make the move during, when I end my bachelors (I think its the equivalente) or my master's.

[@BruceWayne-mf6xf]

In c you can use const keyword for mutability. 😉

[@Phantom-lr6cs]

lazy people love to whiny 24/7 cuz they aren't capable to manage memory XD

[@random6033]

I'm pretty sure C++ standard doesn't specify what algorithm should be used for a hashmap and afaik the implementation in GNU libstdc++ is faster than the one in Rust EDIT: I just tested it with 5000000 insertions, this is the time: C++ (g++): 309 ms C++ (clang): 249.406 milliseconds Rust (rustc): 394 milliseconds

[@ryanlockhart5328]

I don't let the compiler tell me what to do, I'm an American!

[@michaelwulle4055]

Bro began with stating that Rust is higher in productivity as writing javascript then proceeds to proof it by comparing it to C 💀💀💀

[@sneeznoodle]

Conversations with Rust users: Newbie - "God this code takes ages to write feels unnecessarily verbose" Professional - "ACTUALLY THAT'S A GOOD THING YOU'RE JUST A BAD PROGRAMMER RUST IS FLAWLESS" Conversations with C/C++ users: Newbie - "God this fucking language is horrible and I'm in immense pain" Professional - "yep" Just to clarify, I genuinely think Rust is probably a better language than C/C++ and I'm all for its widespread adoption, but holy shit if I don't find people constantly singing its praises annoying

[@raylopez99]

As a sometime FORTRAN77 programmer (which is now an OOP) I approve of this video (I just hobby code; am learning Rust).

[@programming_and_learning]

Need some in deepth tutorial for the community

[@teosfikas8289]

Segmentation Error is a favorite friend, a lover long lost that every time i code happen to find. Ingiting a spark of some kind of untreated abusing love. Jokes aside memory unsafety could also be a tool for perfomance kernels. Not the best way of working but it is a possibility, and Rust still enables you to use it under unsafe {}.