Hacker News Reader

Hacker News

Comment by anymouse123456 | Hacker News Reader

Parent Full thread

anymouse123456

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.

View on HN

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

Jesus wasn't written in Rust? Sounds like a recipe for UB if you ask me.

That's very funny, Jesus was pretty much undefined behavior personified from the perspective of the state/church.

I mean, there was an enormous privilege escalation built in.

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.

every technology has proponents

but Rust evangelism is on another level

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.

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

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.

> boy does the JVM suck outside of server deployments

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.

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

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.

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.

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

I don't think that's true. They've co-evolved, but C simply does less.

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.

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

Real projects get into the millions of lines of code, Rust will not scale to compile that quickly.

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.

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.

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.

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/

> Good for you. > 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.

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

"How to install and use "make" in Windows?"

https://stackoverflow.com/questions/32127524/how-to-install-...

If you can figure out installing a C compiler, surely you can figure out installing make?

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

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

This is a fair response! Thank you. We can disagree on these things and I'd still gladly buy you a beer.

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.

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

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

> I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly

Do you mean the "Rust" programs are assembly?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> Do you mean

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

Do you mean the "Rust" programs are assembly but the "C" programs forced them to be that way?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

No I don't mean.

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?

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

Might not.

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.

> And sure, it’s possible …

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

> Because anecdote

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.

The quoted text seems dictionary definition anecdote.

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.

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.

Reply on news.ycombinator.com