5 ms·

Rust is not free of trade offs and you're not helping the cause the way you think you are. Just a few off the top: - Rust is a much more complex language than

Rust is not free of trade offs and you're not helping the cause the way you think you are. Just a few off the top: - Rust is a much more complex language than C - Rust has a much, much slower compiler than pretty much any language out there - Rust takes most people far longer to "feel" productive - Rust applications are sometimes (often?) slower than comparable C applications - Rust applications are sometimes (often?) larger than comparable C applications You may not value these things, or you may value other things more. That's completely fine, but please don't pretend as if Rust makes zero trade offs in exchange for the safety that people seem to value so much.

Ygg2 2y ago
> Rust is a much more complex language than C Feature wise, yes. C forces you to keep a lot of irreducible complexity in your head. > Rust has a much, much slower compiler than pretty much any language out there True. But it doesn't matter much in my opinion. A decent PC should be able to grind any Rust project in few seconds. > Rust applications are sometimes Sometimes is a weasel word. C is sometimes slower than Java. > Rust takes most people far longer to "feel" productive C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. Or I can write same stuff in Rust and run tests. Run miri and bigger test suite if I'm using unsafe. Maybe fuzz test.
- TingPing 2y ago
  Real projects get into the millions of lines of code, Rust will not scale to compile that quickly.
  - IshKebab 2y ago
    Not quickly, no. But neither does C++ (how long does it take to compile Clang?) and people manage fine. Faster would obviously be better, but it's not big enough of a deal to cancel out all the advantages compared to C.
    - imtringued 2y ago
      I remember a project that used boost for very few things, but it included a single boost header in almost every file. That one boost header absolutely inflated the build times to insane levels.
    - accelbred 2y ago
      I once moved a C++ project to C, and compile times went from 15 minutes to 5 seconds. It was a huge productivity boost. LLVM being slow to compile is also one of the reasons the Zig folk are looking to make it an optional dependency.
- thih9 2y ago
  Good for you. Like the grandparent commenter said, for others these tradeoffs might be important. E.g.: > I am disappointed with how poorly Rust's build scales, even with the incremental test-utf-8 benchmark which shouldn't be affected that much by adding unrelated files. (...) > I decided to not port the rest of quick-lint-js to Rust. But... if build times improve significantly, I will change my mind! https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
  - Ygg2 2y ago
    > Good for you. > https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ Look you're picking a memory unsafe language versus a safe one. Whatever meager gains you save on compilation times (and the link shows the difference is meager if you aren't on a MacOS, which I'm not) will be obliterated by losses in figuring out which UB nasal demon was accidentally released. This is like that argument that dynamic types save time, because you can catch error in tests. But then have to write more tests to compensate, so you lose time overall.
- __d 2y ago
  > C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. So … make && make check ?
  - tcfhgj 2y ago
    "How to install and use "make" in Windows?" https://stackoverflow.com/questions/32127524/how-to-install-and-use-make-in-windows https://stackoverflow.com/questions/32127524/how-to-install-...
    - __d 2y ago
      If you can figure out installing a C compiler, surely you can figure out installing make?
- kelnos 2y ago
  > A decent PC should be able to grind any Rust project in few seconds. That is demonstrably false, unless your definition of "decent PC" is something that costs $4000. I love Rust, but saying misleading (at best) things about build times is not a way to evangelize.
  - Ygg2 2y ago
    > That is demonstrably false, unless your definition of "decent PC" is something that costs $4000. How is it demonstrably false? I'm on 5900x and Rust compilation speed was never an issue for me. More like $1500. $500 for 9950x. $200 for Mobo, $200 for memory and $100 for 1Tb ssd and power supply for $100. Coolers and case by desire. GPU optional. Only way to get to $4000 in a PC is you are buying fancy components or you bought latest xx90 card.
- anymouse123456 2y ago
  This is a fair response! Thank you. We can disagree on these things and I'd still gladly buy you a beer.
- uecker 2y ago
  I don't feel like I need to keep a lot of complexity in my head for C. But one needs to have a concept of how to organize things. I guess Rust forces this onto you.
- astrange 2y ago
  > C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. Have you tried looking around and noticing nobody else does that and it's, like, fine?
criddell 2y ago
> helping the cause Rust evangelism is probably the worst part of Rust. Shallow comments stating Rust’s superiority read to me like somebody who wants to tell me about Jesus.
- codr7 2y ago
  [flagged]
- ubercore 2y ago
  Jesus wasn't written in Rust? Sounds like a recipe for UB if you ask me.
  - codr7 2y ago
    That's very funny, Jesus was pretty much undefined behavior personified from the perspective of the state/church.
    - kstrauser 2y ago
      I mean, there was an enormous privilege escalation built in.
- tcfhgj 2y ago
  it's not unique for Rust, C/C++ devs probably aren't just used to it, since there hasn't been anything major new for decades. If you already dislike this, I ask you to read C-evangelism with respect to the recent Linux drama about Rust in Linux.
  - hu3 2y ago
    every technology has proponents but Rust evangelism is on another level
checker659 2y ago
Not to mention, modern CPUs have essentially been designed to make C code run as fast as possible.
- codr7 2y ago
  I haven't designed any CPUs myself, someone with more experience could give you more details. But I don't think this carries much weight anymore, might have been true way back in the days. C gives you more control, which means it's possible to go faster if you know exactly what you're doing.
- kelnos 2y ago
  Definitely not true. One look at what a modern C compiler does to optimize the code you give it will disabuse you of that notion. There's nothing special or magic about C code, and, if anything, C has moved further and further away from its "portable assembler" moniker over time. And compilers can emit very similar machine instructions for the same type of algorithm regardless of whether you're writing C, Rust, Go, Zig, etc. Consider, for example, that clang/LLVM doesn't even really compile C. The C is first translated into LLVM's IR, which is then used to emit machine instructions.
  - jcranmer 2y ago
    It sort of is and isn't true. CPUs are designed to make certain programming models work very well, and they've done so at the costs of making other kinds of programming paradigms work well (as compared to, say, a GPU, which wants a programming model for which C and C-like languages are clearly ill-fitting). So it's not a wrong statement if you think of it as "designed for C-like languages." But if you're using it in the sense of "C is a privileged language in terms of its connection to hardware architecture, " well, C isn't, and that statement is patently false. There's not a major difference between C, C++, Rust, Zig--even going as far afield as bytecode languages like Java and C#, or fully interpreted stuff like Python or Perl, especially as far as computer architects are concerned. (And in the sense of "this is the language that architects care most about for tuning performance," I think that's actually C++, simply because that tends to be the language for the proprietary HPC software that pays the big bucks for compiler support.)
imtringued 2y ago
That's fair, but to me what drags C and C++ really down for me is the difficulty in building them. As I get older I just want to write the code and not mess with makefiles or CMake. I don't want starting a new project to be a "commitment" that requires me to sit down for two hours. For me Rust isn't really competing against unchecked C. It's competing against Java and boy does the JVM suck outside of server deployments. C gets disqualified from the beginning, so what you're complaining about falls on deaf ears. I'm personally suffering the consequences of "fast" C code every day. There are days where 30 minutes of my time are being wasted on waiting for antivirus software. Thinks that ought to take 2 seconds take 2 minutes. What's crazy is that in a world filled with C programs, you can't say with a good conscience that antivirus software is unnecessary.
- ryandrake 2y ago
  > That's fair, but to me what drags C and C++ really down for me is the difficulty in building them. As I get older I just want to write the code and not mess with makefiles or CMake. I don't want starting a new project to be a "commitment" that requires me to sit down for two hours. Also, integrating 3rd party code has always been one of the worst parts of writing a C or C++ program. This 3p library uses Autoconf/Automake, that one uses CMake, the other one just ships with a Visual Studio .sln file... I want to integrate them all into my own code base with one build system. That is going to be a few hours or days of sitting there and figuring out which .c and .h files need to be considered, where they are, what build flags and -Ddefines are needed, how the build configuration translates into the right build flags and so on. On more modern languages, that whole drama is done with pip install or cargo install.
- arp242 2y ago
  Starting doesn't need to be more difficult than: .PHONY: all all: cc -o progname -std=c99 -pedantic -Wall -Wextra -Wpedantic -O0 *.c Or something along those lines. Move some stuff to variables (CC, CFLAGS, etc.) for release. Can use object files for larger programs (but often isn't needed, certainly not when starting out). I do agree that the general experience of Rust is a lot better. But I also think a lot of C projects have overcomplicated build systems that aren't really needed.
- 2y ago
dralley 2y ago
Many of these are false? * Rust is vastly easier to get started with as a new programmer than C or C++. The quality and availability of documentation, tutorials, tooling, ease of installation, ease of dependency management, ease of writing tests, etc. Learning C basically requires learning make / cmake / meson on top of the language, and maybe Valgrind and the various sanitizers too. C's "simplicity" is not always helpful to someone getting started. * The Rust compiler isn't particularly slow. LLVM is slow. Monomorphization hurts the language, but any other language that made the same tradeoff would see the same problems. The compiler has also gotten much much faster in the last few years and switching linkers or compiler backends makes a huge difference. * Orgs that have studied tracked this don't find Rust to be less productive. Within a couple of months programmers tend to be just as if not more productive than they were previously with other languages. The ramp-up is probably slower than, say, Go, but it's not Scala / Haskell. And again, the tooling & built in test framework really helps with productivity. * Rust applications are very rarely slower than comparable C applications * Rust applications do tend to be larger than comparable C applications, but largely because of static vs. dynamic linking and larger debuginfo.
- anymouse123456 2y ago
  Sorry bud. Neither of our opinions make someone else's opinion false. - Rust may have felt easier for you or some, but certainly not everyone or even most. It might be worth it, but it's not an easy on ramp for many. - Excuses for slow compile times don't make compile times faster. - That's why I said "feel." There are warm fuzzy and cold prickly human things in here. Studies that pretend at measuring something we all know cannot be measured are summarily dismissed. - More excuses do not make a statement false. Rust compile times are some of the slowest I have seen in >25 years of development. Again, the trade-offs work for many people and orgs. That's great! That doesn't make them disappear or become, "false." It's precisely this tone and attitude (that is so prevalent in the community) that keeps so many of us away.
nindalf 2y ago
> Rust applications are sometimes (often?) slower than comparable C applications Could you cite some examples? There are plenty of counter-examples - ripgrep is 5-10x faster than grep (https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf2187cd34c2a7f6cf32e2a4903/benchsuite/runs/2022-12-16-archlinux-duff/summary https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21...). There's a reason ripgrep is embedded within VS Code to power search. - Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/ https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...) - The Rust implementation of GNU Coreutils compares favourably in performance. For example, uutils/sort outperforms coreutils/sort by 6x while working on every mainstream OS - Linux, FreeBSD, NetBSD, OpenBSD, Illumos, Redox, Android, macOS, and Windows.(https://lwn.net/Articles/1007907/ https://lwn.net/Articles/1007907/) - Android rewrote their IPC code (Binder) from C to Rust. The Rust version is within +- 1-2% of the C version (https://www.phoronix.com/news/Google-Linux-Binder-In-Rust https://www.phoronix.com/news/Google-Linux-Binder-In-Rust). - rustls outperforms OpenSSL and BoringSSL (https://www.memorysafety.org/blog/rustls-performance-outperforms/ https://www.memorysafety.org/blog/rustls-performance-outperf...) - zlib-rs is the fastest implementation of zlib (https://www.phoronix.com/news/Zlib-rs-0.4.2 https://www.phoronix.com/news/Zlib-rs-0.4.2) - Advent of Code - The one C example I saw executed the first 10 days of 2024 in 36ms (https://www.reddit.com/r/adventofcode/comments/1hbcyhz/comment/m1fapgz/ https://www.reddit.com/r/adventofcode/comments/1hbcyhz/comme...), while my idiomatic Rust solutions (https://github.com/nindalf/advent https://github.com/nindalf/advent) took 10.1ms. I'm not even that good, there are Rust solutions 10x faster than mine - https://github.com/maneatingape/advent-of-code-rust https://github.com/maneatingape/advent-of-code-rust. - I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly, but Rust and C are comparable in speed (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...) So yes, I'm surprised by your claim of C programs "often" outperforming comparable Rust programs, but I'd be interested to know if even the "sometimes" is true. Please share if you've found any. The other claims are questionable as well, but this one was the most easily disproven.
- igouy 2y ago

Ygg2 2y ago

> Rust is a much more complex language than C Feature wise, yes. C forces you to keep a lot of irreducible complexity in your head. > Rust has a much, much slower compiler than pretty much any language out there True. But it doesn't matter much in my opinion. A decent PC should be able to grind any Rust project in few seconds. > Rust applications are sometimes Sometimes is a weasel word. C is sometimes slower than Java. > Rust takes most people far longer to "feel" productive C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. Or I can write same stuff in Rust and run tests. Run miri and bigger test suite if I'm using unsafe. Maybe fuzz test.

TingPing 2y ago
Real projects get into the millions of lines of code, Rust will not scale to compile that quickly.
- IshKebab 2y ago
  Not quickly, no. But neither does C++ (how long does it take to compile Clang?) and people manage fine. Faster would obviously be better, but it's not big enough of a deal to cancel out all the advantages compared to C.
  - imtringued 2y ago
    I remember a project that used boost for very few things, but it included a single boost header in almost every file. That one boost header absolutely inflated the build times to insane levels.
  - accelbred 2y ago
    I once moved a C++ project to C, and compile times went from 15 minutes to 5 seconds. It was a huge productivity boost. LLVM being slow to compile is also one of the reasons the Zig folk are looking to make it an optional dependency.
thih9 2y ago
Good for you. Like the grandparent commenter said, for others these tradeoffs might be important. E.g.: > I am disappointed with how poorly Rust's build scales, even with the incremental test-utf-8 benchmark which shouldn't be affected that much by adding unrelated files. (...) > I decided to not port the rest of quick-lint-js to Rust. But... if build times improve significantly, I will change my mind! https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
- Ygg2 2y ago
  > Good for you. > https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ Look you're picking a memory unsafe language versus a safe one. Whatever meager gains you save on compilation times (and the link shows the difference is meager if you aren't on a MacOS, which I'm not) will be obliterated by losses in figuring out which UB nasal demon was accidentally released. This is like that argument that dynamic types save time, because you can catch error in tests. But then have to write more tests to compensate, so you lose time overall.
__d 2y ago
> C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. So … make && make check ?
- tcfhgj 2y ago
  "How to install and use "make" in Windows?" https://stackoverflow.com/questions/32127524/how-to-install-and-use-make-in-windows https://stackoverflow.com/questions/32127524/how-to-install-...
  - __d 2y ago
    If you can figure out installing a C compiler, surely you can figure out installing make?
kelnos 2y ago
> A decent PC should be able to grind any Rust project in few seconds. That is demonstrably false, unless your definition of "decent PC" is something that costs $4000. I love Rust, but saying misleading (at best) things about build times is not a way to evangelize.
- Ygg2 2y ago
  > That is demonstrably false, unless your definition of "decent PC" is something that costs $4000. How is it demonstrably false? I'm on 5900x and Rust compilation speed was never an issue for me. More like $1500. $500 for 9950x. $200 for Mobo, $200 for memory and $100 for 1Tb ssd and power supply for $100. Coolers and case by desire. GPU optional. Only way to get to $4000 in a PC is you are buying fancy components or you bought latest xx90 card.
anymouse123456 2y ago
This is a fair response! Thank you. We can disagree on these things and I'd still gladly buy you a beer.
uecker 2y ago
I don't feel like I need to keep a lot of complexity in my head for C. But one needs to have a concept of how to organize things. I guess Rust forces this onto you.
astrange 2y ago
> C takes me more time to feel productive. I have to write code, then unit test, then property tests, then run valgrind, check ubsan is on. Make more tests. Do property testing, then fuzz testing. Have you tried looking around and noticing nobody else does that and it's, like, fine?

criddell 2y ago

> helping the cause Rust evangelism is probably the worst part of Rust. Shallow comments stating Rust’s superiority read to me like somebody who wants to tell me about Jesus.

codr7 2y ago
[flagged]
ubercore 2y ago
Jesus wasn't written in Rust? Sounds like a recipe for UB if you ask me.
- codr7 2y ago
  That's very funny, Jesus was pretty much undefined behavior personified from the perspective of the state/church.
  - kstrauser 2y ago
    I mean, there was an enormous privilege escalation built in.
tcfhgj 2y ago
it's not unique for Rust, C/C++ devs probably aren't just used to it, since there hasn't been anything major new for decades. If you already dislike this, I ask you to read C-evangelism with respect to the recent Linux drama about Rust in Linux.
- hu3 2y ago
  every technology has proponents but Rust evangelism is on another level

checker659 2y ago

Not to mention, modern CPUs have essentially been designed to make C code run as fast as possible.

codr7 2y ago
I haven't designed any CPUs myself, someone with more experience could give you more details. But I don't think this carries much weight anymore, might have been true way back in the days. C gives you more control, which means it's possible to go faster if you know exactly what you're doing.
kelnos 2y ago
Definitely not true. One look at what a modern C compiler does to optimize the code you give it will disabuse you of that notion. There's nothing special or magic about C code, and, if anything, C has moved further and further away from its "portable assembler" moniker over time. And compilers can emit very similar machine instructions for the same type of algorithm regardless of whether you're writing C, Rust, Go, Zig, etc. Consider, for example, that clang/LLVM doesn't even really compile C. The C is first translated into LLVM's IR, which is then used to emit machine instructions.
- jcranmer 2y ago
  It sort of is and isn't true. CPUs are designed to make certain programming models work very well, and they've done so at the costs of making other kinds of programming paradigms work well (as compared to, say, a GPU, which wants a programming model for which C and C-like languages are clearly ill-fitting). So it's not a wrong statement if you think of it as "designed for C-like languages." But if you're using it in the sense of "C is a privileged language in terms of its connection to hardware architecture, " well, C isn't, and that statement is patently false. There's not a major difference between C, C++, Rust, Zig--even going as far afield as bytecode languages like Java and C#, or fully interpreted stuff like Python or Perl, especially as far as computer architects are concerned. (And in the sense of "this is the language that architects care most about for tuning performance," I think that's actually C++, simply because that tends to be the language for the proprietary HPC software that pays the big bucks for compiler support.)

imtringued 2y ago

That's fair, but to me what drags C and C++ really down for me is the difficulty in building them. As I get older I just want to write the code and not mess with makefiles or CMake. I don't want starting a new project to be a "commitment" that requires me to sit down for two hours. For me Rust isn't really competing against unchecked C. It's competing against Java and boy does the JVM suck outside of server deployments. C gets disqualified from the beginning, so what you're complaining about falls on deaf ears. I'm personally suffering the consequences of "fast" C code every day. There are days where 30 minutes of my time are being wasted on waiting for antivirus software. Thinks that ought to take 2 seconds take 2 minutes. What's crazy is that in a world filled with C programs, you can't say with a good conscience that antivirus software is unnecessary.

ryandrake 2y ago
> That's fair, but to me what drags C and C++ really down for me is the difficulty in building them. As I get older I just want to write the code and not mess with makefiles or CMake. I don't want starting a new project to be a "commitment" that requires me to sit down for two hours. Also, integrating 3rd party code has always been one of the worst parts of writing a C or C++ program. This 3p library uses Autoconf/Automake, that one uses CMake, the other one just ships with a Visual Studio .sln file... I want to integrate them all into my own code base with one build system. That is going to be a few hours or days of sitting there and figuring out which .c and .h files need to be considered, where they are, what build flags and -Ddefines are needed, how the build configuration translates into the right build flags and so on. On more modern languages, that whole drama is done with pip install or cargo install.
arp242 2y ago
Starting doesn't need to be more difficult than: .PHONY: all all: cc -o progname -std=c99 -pedantic -Wall -Wextra -Wpedantic -O0 *.c Or something along those lines. Move some stuff to variables (CC, CFLAGS, etc.) for release. Can use object files for larger programs (but often isn't needed, certainly not when starting out). I do agree that the general experience of Rust is a lot better. But I also think a lot of C projects have overcomplicated build systems that aren't really needed.
2y ago

dralley 2y ago

Many of these are false? * Rust is vastly easier to get started with as a new programmer than C or C++. The quality and availability of documentation, tutorials, tooling, ease of installation, ease of dependency management, ease of writing tests, etc. Learning C basically requires learning make / cmake / meson on top of the language, and maybe Valgrind and the various sanitizers too. C's "simplicity" is not always helpful to someone getting started. * The Rust compiler isn't particularly slow. LLVM is slow. Monomorphization hurts the language, but any other language that made the same tradeoff would see the same problems. The compiler has also gotten much much faster in the last few years and switching linkers or compiler backends makes a huge difference. * Orgs that have studied tracked this don't find Rust to be less productive. Within a couple of months programmers tend to be just as if not more productive than they were previously with other languages. The ramp-up is probably slower than, say, Go, but it's not Scala / Haskell. And again, the tooling & built in test framework really helps with productivity. * Rust applications are very rarely slower than comparable C applications * Rust applications do tend to be larger than comparable C applications, but largely because of static vs. dynamic linking and larger debuginfo.

anymouse123456 2y ago
Sorry bud. Neither of our opinions make someone else's opinion false. - Rust may have felt easier for you or some, but certainly not everyone or even most. It might be worth it, but it's not an easy on ramp for many. - Excuses for slow compile times don't make compile times faster. - That's why I said "feel." There are warm fuzzy and cold prickly human things in here. Studies that pretend at measuring something we all know cannot be measured are summarily dismissed. - More excuses do not make a statement false. Rust compile times are some of the slowest I have seen in >25 years of development. Again, the trade-offs work for many people and orgs. That's great! That doesn't make them disappear or become, "false." It's precisely this tone and attitude (that is so prevalent in the community) that keeps so many of us away.

nindalf 2y ago

> Rust applications are sometimes (often?) slower than comparable C applications Could you cite some examples? There are plenty of counter-examples - ripgrep is 5-10x faster than grep (https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf2187cd34c2a7f6cf32e2a4903/benchsuite/runs/2022-12-16-archlinux-duff/summary https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21...). There's a reason ripgrep is embedded within VS Code to power search. - Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/ https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...) - The Rust implementation of GNU Coreutils compares favourably in performance. For example, uutils/sort outperforms coreutils/sort by 6x while working on every mainstream OS - Linux, FreeBSD, NetBSD, OpenBSD, Illumos, Redox, Android, macOS, and Windows.(https://lwn.net/Articles/1007907/ https://lwn.net/Articles/1007907/) - Android rewrote their IPC code (Binder) from C to Rust. The Rust version is within +- 1-2% of the C version (https://www.phoronix.com/news/Google-Linux-Binder-In-Rust https://www.phoronix.com/news/Google-Linux-Binder-In-Rust). - rustls outperforms OpenSSL and BoringSSL (https://www.memorysafety.org/blog/rustls-performance-outperforms/ https://www.memorysafety.org/blog/rustls-performance-outperf...) - zlib-rs is the fastest implementation of zlib (https://www.phoronix.com/news/Zlib-rs-0.4.2 https://www.phoronix.com/news/Zlib-rs-0.4.2) - Advent of Code - The one C example I saw executed the first 10 days of 2024 in 36ms (https://www.reddit.com/r/adventofcode/comments/1hbcyhz/comment/m1fapgz/ https://www.reddit.com/r/adventofcode/comments/1hbcyhz/comme...), while my idiomatic Rust solutions (https://github.com/nindalf/advent https://github.com/nindalf/advent) took 10.1ms. I'm not even that good, there are Rust solutions 10x faster than mine - https://github.com/maneatingape/advent-of-code-rust https://github.com/maneatingape/advent-of-code-rust. - I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly, but Rust and C are comparable in speed (https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...) So yes, I'm surprised by your claim of C programs "often" outperforming comparable Rust programs, but I'd be interested to know if even the "sometimes" is true. Please share if you've found any. The other claims are questionable as well, but this one was the most easily disproven.

igouy 2y ago