6 ms·

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'

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.

0cf8612b2e1e 1y ago
Every cycle saved is longer battery life. Someone paid the one time cost of porting it, and now we can enjoy better performance forever.
- dale_huevo 1y ago
  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.
  - jimktrains2 1y ago
    Isn't bzip used quite a bit, especially for tar files?
    - jeffbee 1y ago
      If so, only by misguided users. Why would anyone choose bz2 in 2025?
      - 0x457 1y ago
        To unpack an archive made from the time when bz2 was used?
      - ben-schaaf 1y ago
        Of course no one uses systems, tools and files created before 2025!
        jeffbee 1y ago
        bzip2 hasn't been the best at anything in at least 20 years.
        appreciatorBus 1y ago
        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.
        MBCook 1y ago
        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.
      - Twirrim 1y ago
        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.
      - kbolino 1y ago
        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.
    - Philpax 1y ago
      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_Wikipedia https://meta.wikimedia.org/wiki/Data_dump_torrents#English_W...
  - deleted 1y ago
    [deleted]
  - yuriks 1y ago
    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.
    - spartanatreyu 1y ago
      Exactly, even if we can't remove "that one dependency" (https://xkcd.com/2347/ https://xkcd.com/2347/), we can reinforce everything that uses it.
Rucadi 1y ago
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.
Terr_ 1y ago
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.
- wahern 1y ago
  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.
_zagj 1y ago
> Counting CPU cycles And that's assuming they aren't lying about the counting: https://desuarchive.org/g/thread/104831348/#q104831479 https://desuarchive.org/g/thread/104831348/#q104831479
- DaSHacka 1y ago
  Rust devs continuing to use misleading benchmarks? I, for one, am absolutely shocked. Flabbergasted, even.
- dwattttt 1y ago
  Do you have any reason to think their numbers are wrong, or is your argument "someone else once lied, maybe they are too"?
jxjnskkzxxhx 1y ago
> 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.
cornstalks 1y ago
> 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.
viraptor 1y ago
Those cycles translate directly to $ saved in a few places. Mostly in places far away from having any UI at all.
tcfhgj 1y ago
> 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
- stevefan1999 1y ago
  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 https://www.comp.nus.edu.sg/~damithch/quotes/quote27.htm [^2]: https://www.greenchoices.org/news/blog-posts/the-jevons-paradox-when-efficiency-leads-to-increased-consumption https://www.greenchoices.org/news/blog-posts/the-jevons-para... [^3]: https://quickonomics.com/terms/jevons-paradox/ https://quickonomics.com/terms/jevons-paradox/
  - hyperman1 1y ago
    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
bitwize 1y ago
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.
- Surac 1y ago
  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
  - zaphar 1y ago
    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.
- panick21_ 1y ago
  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.
Scuds 1y ago
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.
hoseja 1y ago
It's like "adapting" Akallabêth so you can tell your own empowering story for modern audiences.
SpaceNugget 1y ago
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?
egorfine 1y ago
I fully agree with you on the first statement and I am at loss of words at the second...

0cf8612b2e1e 1y ago

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

dale_huevo 1y ago
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.
- jimktrains2 1y ago
  Isn't bzip used quite a bit, especially for tar files?
  - jeffbee 1y ago
    If so, only by misguided users. Why would anyone choose bz2 in 2025?
    - 0x457 1y ago
      To unpack an archive made from the time when bz2 was used?
    - ben-schaaf 1y ago
      Of course no one uses systems, tools and files created before 2025!
      - jeffbee 1y ago
        bzip2 hasn't been the best at anything in at least 20 years.
        appreciatorBus 1y ago
        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.
        MBCook 1y ago
        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.
    - Twirrim 1y ago
      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.
    - kbolino 1y ago
      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.
  - Philpax 1y ago
    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_Wikipedia https://meta.wikimedia.org/wiki/Data_dump_torrents#English_W...
- deleted 1y ago
  [deleted]
- yuriks 1y ago
  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.
  - spartanatreyu 1y ago
    Exactly, even if we can't remove "that one dependency" (https://xkcd.com/2347/ https://xkcd.com/2347/), we can reinforce everything that uses it.

Rucadi 1y ago

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.

Terr_ 1y ago

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.

wahern 1y ago
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.

_zagj 1y ago

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

DaSHacka 1y ago
Rust devs continuing to use misleading benchmarks? I, for one, am absolutely shocked. Flabbergasted, even.
dwattttt 1y ago
Do you have any reason to think their numbers are wrong, or is your argument "someone else once lied, maybe they are too"?

jxjnskkzxxhx 1y ago

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

cornstalks 1y ago

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

viraptor 1y ago

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

tcfhgj 1y ago

> 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

stevefan1999 1y ago
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 https://www.comp.nus.edu.sg/~damithch/quotes/quote27.htm [^2]: https://www.greenchoices.org/news/blog-posts/the-jevons-paradox-when-efficiency-leads-to-increased-consumption https://www.greenchoices.org/news/blog-posts/the-jevons-para... [^3]: https://quickonomics.com/terms/jevons-paradox/ https://quickonomics.com/terms/jevons-paradox/
- hyperman1 1y ago
  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

bitwize 1y ago

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.

Surac 1y ago
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
- zaphar 1y ago
  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.
panick21_ 1y ago
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.

Scuds 1y ago

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.

hoseja 1y ago

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

SpaceNugget 1y ago

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?

egorfine 1y ago

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