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:

#programming #code #software

[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).

[orbital]

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.

[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.

[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, ...)

[mattpattok]

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.

[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.

[eddiebreeg]

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 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.

[darioabbece]

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

[bagel]

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++

[mailman]

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 👍

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

[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

[VivekYadav-dsoz]

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.

[_M_]

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

[HotWings]

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.

[NostraDavid]

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

[random]

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 insertions, this is the time:
C++ (g++): 309 ms
C++ (clang): 249.406 milliseconds
Rust (rustc): 394 milliseconds

[kevinyonan]

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

[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.

[chrishusky]

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