Rust vs C: The Programming Battle You Didn't See Coming!

In this video, we dive into the ultimate showdown between Rust and C, two powerful programming languages with distinct strengths. We'll compare them on key factors like execution speed, memory safety, job opportunities, community size, and more.

Discover why Rust is gaining popularity among big tech companies like AWS, Microsoft, and Apple, and how it challenges C's decades-long dominance. Is Rust truly safer? Can it replace C in the future? Or does C still hold its throne in the programming world?

Join us as we explore the facts, run real-world tests, and uncover insights that might surprise you. Don't miss the epic battle of programming giants!

[CallousCoder]

Rust will not replace C, not ever. Zig has a better chance in that, as it seamlessly can integrate with existing code. Companies will not throw away tried and tested (and if you are in critical systems even proved) libraries.

[ericshimizukarbstein]

0:21 What are the operations being done inside the loop? It may look similar, and even having the same output, but more often than not, not really doing the same thing. A classical example are IO as the standard C IO structure `FILE` stream is buffered by default, while in Rust is unbuffered by default, and that makes a huge difference. As someone that is implementing a libc in no_std Rust I can confidently say that there are many differences in the way Rust and C standard libraries work to "produce the same feature" that are simply not the same for a number of different reasons.

Returning to the IO streams, Rust chose unbuffered by default because it has generics/methods/traits that make it easier to do type composition to get what you may want while being explicit of what it is, so you type usage tells the history of the problem being solved. A File type is whatever is the file handle of the OS, what it buffered, use BufReader/BufWriter that takes the File. While the C FILE stream is nice for C because is one structure that may work buffered, line-buffered or unbuffered, but for perf reasons is buffered by default, since it doesn't have such nice things Rust has, a configurable type is the way to go.

[Baptistetriple]

Stopped watching when I saw the times at 0:24, comparing debug builds is completly irrelevant, if the rust code was compiled in release mode the loop would have taken 0ms, because the compiler would have just removed it. Rust debug builds are slow because there is a high amount of abstractions in the language and they are not optmized away in debug, but oh boi do the optimizer is good when you enable it. And comparing 2 compiled languages speed is always irrelvant, the only thing you are comparing is the optimizer, you can produce the exact same machine code in both languages.