[HN Gopher] Bzip2 crate switches from C to 100% Rust
___________________________________________________________________
Bzip2 crate switches from C to 100% Rust
Author : Bogdanp
Score : 78 points
Date : 2025-06-17 20:06 UTC (2 hours ago)
(HTM) web link (trifectatech.org)
(TXT) w3m dump (trifectatech.org)
| dralley wrote:
| How realistic is it for the Trifecta Tech implementation to start
| displacing the "official" implementation used by linux distros,
| which hasn't seen an upstream release since 2019?
|
| Fedora recently swapped the original Adler zlib implementation
| with zlib-ng, so that sort of thing isn't impossible. You just
| need to provide a C ABI compatible with the original one.
| masfuerte wrote:
| They do provide a compatible C ABI. Someone "just" needs to do
| the work to make it happen.
| rlpb wrote:
| > You just need to provide a C ABI compatible with the original
| one.
|
| How does this interact with dynamic linking? Doesn't the
| current Rust toolchain mandate static linking?
| sedatk wrote:
| No. https://doc.rust-
| lang.org/reference/linkage.html#r-link.dyli...
| arcticbull wrote:
| Rust lets you generate dynamic C-linkage libraries.
|
| Use crate-type=["cdylib"]
| nicoburns wrote:
| Dynamic linking works fine if you target the C ABI.
| anonnon wrote:
| > Improved performance
|
| After the uutils debacle, does anyone still trust these "rewrote
| in Rust" promotional benchmarks without independent verification?
| jeffbee wrote:
| You should of course verify these results in your scenario.
| However, I somewhat doubt that the person exists who cares
| greatly about performance, and is still willing to consider
| bzip2. There isn't a point anywhere in the design space where
| bzip2 beats zstd. You can get smaller outputs from zstd in
| 1/20th the time for many common inputs, or you can spend the
| same amount of time and get a significantly smaller output, and
| zstd decompression is again 20-50x faster depending. So the
| speed of your bzip2 implementation hardly seems worth arguing
| over.
| dale_huevo wrote:
| 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 wrote:
| 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 wrote:
| 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, for example, eye candy no one asked
| for, then no one is counting and the comparison is
| irrelevant.
| jimktrains2 wrote:
| Isn't bzip used quite a bit, especially for tar files?
| jeffbee wrote:
| If so, only by misguided users. Why would anyone choose
| bz2 in 2025?
| Rucadi wrote:
| 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_ wrote:
| [delayed]
| firesteelrain wrote:
| Anyone know if this will by default resolve the 11 outstanding
| CVEs?
|
| Ironically there is one CVE reported in the bzip2 crate
|
| [1]
| https://app.opencve.io/cve/?product=bzip2&vendor=bzip2_proje...
___________________________________________________________________
(page generated 2025-06-17 23:00 UTC)