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.
If you already dislike this, I ask you to read C-evangelism with respect to the recent Linux drama about Rust in Linux.
but Rust evangelism is on another level
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.
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.
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.)
I've never seen a good way to make a CPU that's good for "not C" languages. Those are usually by people who are aggressively uninterested in being fast and so insist on semantics that simply wouldn't get faster if done in hardware. Like the way most Haskell programs execute is just bad and based on bad ideas.
But in both cases, modern CPUs are mostly network- then I/O- then memory-bound. Most C programs aren't written to respect that very well.
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.
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.
.PHONY: all
all:
cc -o progname -std=c99 -pedantic -Wall -Wextra -Wpedantic -O0 *.c
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.
Does it? Why? Is it significantly worse than any other language that needs a runtime like Python or Node?
`java -jar foo.jar MainClass` doesn't seem all that bad. Plus you can wrap it in a trivial shell script if you want.
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.
Faster would obviously be better, but it's not big enough of a deal to cancel out all the advantages compared to C.
So … make && make check ?
https://stackoverflow.com/questions/32127524/how-to-install-...
> 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!
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.
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.
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.
Have you tried looking around and noticing nobody else does that and it's, like, fine?
* 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.
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.
Could you cite some examples? There are plenty of counter-examples
- ripgrep is 5-10x faster than grep (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_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/)
- 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).
- rustls outperforms OpenSSL and BoringSSL (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)
- 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/comme...), while my idiomatic Rust solutions (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.
- 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/...)
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.
Do you mean the "Rust" programs are assembly?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
No I don't mean. I said what I said.
If you click the C program right next to the Rust program for "spectral-norm" you get the equally unreadable - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It is possible to write idiomatic Rust and C. It is possible to write assembly in the form of Rust and C. In both cases, they're comparable in performance.
But leaving toy programs like Benchmarks Game and AoC aside, I gave 6 examples of Rust outperforming C. Do you have any examples of C outperforming Rust?
I don't have a pony in that race.
> uutils/sort outperforms coreutils/sort by 6x
"He used the hyperfine command-line benchmarking tool to run a test ten times; sorting a text file containing all of Shakespeare's works to see which implementation was faster. The first time he performed the test, he used a debug build of the Rust version of sort. In that demo, Rust's version was 1.45x faster than the GNU version. Then he ran the test again using a non-debug version, which showed the Rust version performing the test six times faster than GNU's implementation."
Might it be that a new implementation in C would also have been faster?
The Rust standard library has a state of the art sort implementation. There’s nothing faster, in any language - https://github.com/rust-lang/rust/pull/124032.
And sure, it’s possible that someone could write a C program that compares in speed to all the Rust programs I’ve mentioned. C is a Turing complete language after all. I’m only pointing out that it hasn’t happened in practice.
Also check the Android Binder code before (C https://github.com/torvalds/linux/blob/master/drivers/androi...) and after (Rust - https://android.googlesource.com/platform/frameworks/native/...). Same speed but the quality difference, it’s incomparable.
Because anecdote. We can only know when the thing is designed as an experiment.
(All credit to who-so-ever is working to write improved versions.)
I don’t think anyone could have said something more rude or ignorant if they tried.
> designed as an experiment
Ha. As if you could design such an experiment. What, you’ll place two rats at a keyboard and ask them to implement grep? Bffr.
I’m pointing out the obvious - no one has actually written these mythical C programs that outperform Rust, to say nothing about security and reliability. You’ve deluded yourself into thinking that all it needs is “an experiment”. lol.
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.