Hacker News Reader

Comment by dale_huevo | Hacker News Reader

A lot of this "rewrite X in Rust" stuff feels like burning your own house down so you can rebuild and paint it a different color.

Counting CPU cycles as if it's an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.

View on HN

> Counting CPU cycles as if it's an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.

That's the kind of attitude that leads to 50% of modern CPU resources being allocated toward UI eye candy.

Every cycle saved is longer battery life. Someone paid the one time cost of porting it, and now we can enjoy better performance forever.

They kicked off the article saying that no one uses bzip2 anymore. A million cycles saved for something no one uses (according to them) is still 0% battery life saved.

If modern CPUs are so power efficient and have so many spare cycles to allocate to e.g. eye candy no one asked for, then no one is counting and the comparison is irrelevant.

It sounds like the main motivation for the conversion was to simplify builds and reduce the chance of security issues. Old parts of protocols that no one pays much attention to anymore does seem to be a common place where those pop up. The performance gain looks more like just a nice side effect of the rewrite, I imagine they were at most targeting performance parity.

Exactly, even if we can't remove "that one dependency" (https://xkcd.com/2347/), we can reinforce everything that uses it.

Isn't bzip used quite a bit, especially for tar files?

The Wikipedia data dumps [0] are multistream bz2. This makes them relatively easy to partially ingest, and I'm happy to be able to remove the C dependency from the Rust code I have that deals with said dumps.

[0]: https://meta.wikimedia.org/wiki/Data_dump_torrents#English_W...

If so, only by misguided users. Why would anyone choose bz2 in 2025?

To unpack an archive made from the time when bz2 was used?

Of course no one uses systems, tools and files created before 2025!

bzip2 hasn't been the best at anything in at least 20 years.

The same could be said of many things that, nonetheless, are still used by many, and will continue to be used by many for decades to come. A thing does not need to be best to justify someone wanting to make it a bit better.

I use plain old zip files almost every day.

“Best” is measured along a lot more axis than just performance. And you don’t always get to choose what format you use. It may be dictated to you by some 3rd party you can’t influence.

bzip2 is still pretty good if you want to optimize for:

  - better compression ratio than gzip
  - faster compression than many better-than-gzip competitors
  - lower CPU/RAM usage for the same compression ratio/time

This is a niche, but it does crop up sometimes. The downside to bzip2 is that it is slow to decompress, but for write-heavy workloads, that doesn't matter too much.

So? If I need to consume a resource compressed using bz2, I'm not just going to sit around and wait for them to use zstd. I'm going to break out bz2. If I can use a modern rewrite that's faster, I'll take every advantage I can get.

I personally find a lot more relevant the part about "Enabling cross-compilation ", which in my opinion is important and a win.

The same about exported symbols and being able to compile to wasm easily.

> Counting CPU cycles as if it's an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.

Attitude which leads to electron apps replacing native ones, and I hate it. I am not buying better cpus and more ram just to have it wasted like this

You know it is just Wirth's law in action: "Software gets slower faster than hardware gets faster." [^1]

In fact Jevons Paradox: When technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises due to increasing demand - essentially, efficiency improvements can lead to increased consumption rather than the intended conservation. [^2][^3]

[^1]: https://www.comp.nus.edu.sg/~damithch/quotes/quote27.htm

[^2]: https://www.greenchoices.org/news/blog-posts/the-jevons-para...

[^3]: https://quickonomics.com/terms/jevons-paradox/

I think it goes deeper. There is a certain level of slowness that causes pain to users. When that level is hit, market forces cause attention to software efficiency.

Hardware efficiency just gives more room for software to bloat. The pain level is a human factor and stays the same.

So time to adapt Wirths law: Software gets slower >exactly as much< as hardware gets faster

It seems to me like binary file format parsing (and construction) is probably a good place for using languages that aren't as prone to buffer-overflows and the like. Especially if it's for a common format and the code might be used in all sorts of security-contexts.

Buffer overflows are more a library problem, not a language problem, though for newer ecosystems like Rust the distinction is kind of lost on people. But point being, if you rewrote bzip2 using an equivalent to std::Vec, you'd end up in the same place. Unfortunately, the norm among C developers, especially in the past, was to open code most buffer manipulation, so you wind up with 1000 manually written overflow checks, some of which are wrong or outright missing, as opposed to a single check in a shared implementation. Indeed, even that Rust code had an off-by-one (in "safe" code), it just wasn't considered a security issue because it would result in data corruption, not an overflow.

What Rust-the-language does offer is temporal safety (i.e. the borrow checker), and there's no easy way to get that in C.

Those cycles translate directly to $ saved in a few places. Mostly in places far away from having any UI at all.

Pretty incredible for such a short argument to be so inconsistent with itself. Complaining about counting CPU cycles and actually measuring performance because... modern software development is bad and doesn't care about performance?

you're just an end user, you don't have to maintain the suite.

In OSS every hour of volunteer time is precious Manna from heaven, flavored with unicorn tears. So any way to remove Toil and introduce automation is gold.

Rust's strict compiler and an appropriate test suite guarantees a level of correctness far beyond C. There's less onus on the reviewer to ensure everything still works as expected when reviewing a pull request.

It's a win-win situation.

It's like "adapting" Akallabêth so you can tell your own empowering story for modern audiences.

I fully agree with you on the first statement and I am at loss of words at the second...

> lot of this "rewrite X in Rust" stuff feels like

Indeed. You know the react-angular-vue nevermind is churn? It appears that the trend of people pushing stuff because it benefit their careers is coming to the low level world.

I for one still find it mistifying that Linus torvals let this people into the kernel. Linus, who famous banned c++ from the kernel not because of c++ in itself, but to ban c++ programmer culture.

It's a lot like X11 vs. Wayland. The current graphics developers, who trend younger, don't want to maintain the boomer-written C code in the X server. Too risky and time-consuming. So one of the goals of Wayland is to completely abolish X so it can be replaced with something more long-term maintainable. Turns out, current systems-level developers don't want to maintain boomer-written GNU code or any C code at all, really, for similar reasons. C is inherently problematic because even seasoned developers have trouble avoiding its footguns. So an unstated, but important, goal of Rust is to abolish all critical C code and replace it with Rust code. Ubuntu is on board with this.

Except Wayland was developed by the same people who worked for years on X. And they don't dislike X because of C. And they didn't write Wayland in Rust.

> Except Wayland was developed by the same people who worked for years on X.

Yes, and they hated it and "worked hard to kill it" per Jordan Petridis. Note that the maintainers of X in the Wayland era are not really the same people as the original authors of X.

They didn't just maintain it, they did years of work on it. And again, it was not because it was C. Its because it was literally millions of lines of C from 80s and early 90s and with a sub-optimal architecture.

And there is likely a reason the original people didn't continue to work on it.

So you say younger programmer have not the required coding kung fu to cope with c code? I hope you are wrong. The perspective to have rust like things on everydays devices realy frightens me. C is like a Lingua franca for computers. Nearly any hardware near person can READ it. I am one of this Boomers and i am not able to propper READ rust code, because the syntax is so academic. The fact that more and more code is written in rust, lessens the amount of people that can read programs

It's more like no programmer of any age has the required coding kung fu to cope with C code. It is inevitable that they will introduce problematic code. We have decades of examples illustrating this. We lived with it because there was no truly competitive alternative for so long.

I can read and write C code from the times when there weren't any competitive alternatives. I have no problem reading or writing Rust code. In fact it communicates more to me than C code does or can and I can immediately understand more about the code written in Rust than I can about code written in C.

> Counting CPU cycles

And that's assuming they aren't lying about the counting: https://desuarchive.org/g/thread/104831348/#q104831479

Do you have any reason to think their numbers are wrong, or is your argument "someone else once lied, maybe they are too"?

Rust devs continuing to use misleading benchmarks? I, for one, am absolutely shocked. Flabbergasted, even.

Reply on news.ycombinator.com