Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice "feature"?

> [...] doesn't that mean the implementation is just... finished?

I don't think that it _necessarily_ means that, e.g. all projects that haven't had a release since 2019 aren't finished? Probably most of them are simply abandoned?

On the other hand, a finished implementation is certainly a _possible_ explanation for why there have been no releases.

In this specific case, there are a handful of open bugs on their issue tracker. So that would indicate that the project isn't finished.

ref: https://sourceware.org/bugzilla/buglist.cgi?product=bzip2

It's not. At least not yet. It's planned for 25.10, but thankfully sudo will be packaged and available for a few versions after that as promised [1].

[1] https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-i...

1) This is a cool project and I wish them success. It would be really cool if these became the default utilities some day soon.

2) I think the MIT license was a mistake. These are often cloning GNU utilities, so referencing GNU source in its original language and then re-implementing it in Rust would be the obvious thing to do. But porting GPL-licensed code to an MIT licensed project is not allowed. Instead, the utilities must be re-implemented from scratch, which seems like a waste of effort. I would be interested in doing the work of porting GNU source to Rust, but I'm not interested in re-writing them all from scratch, so I haven't contributed to this project.

I hope some are improved too.

The performance boost in tools like ripgrep and tokei is insane compared to the tools they replace (grep and cloc respectively).

The commenters below are confusing two things - Rust binaries can be dynamically linked, but because Rust doesn’t have a stable ABI you can’t do this across compiler versions the way you would with C. So in practice, everything is statically linked.

Rust cannot dynamic link to rust. It can dynamic link to C and be dynamicly linked by C - if you combine the two you can cheat but it is still C that you are dealing with not rust even if rust is on both sides.

No. https://doc.rust-lang.org/reference/linkage.html#r-link.dyli...

Rust lets you generate dynamic C-linkage libraries.

Use crate-type=["cdylib"]

Dynamic linking works fine if you target the C ABI.

Rust importing Rust must be statically linked, yes. You can statically link Rust into a dynamic library that other libraries link to, though!

You can use dynamic linking in Rust with C ABI. Which means going through `unsafe` keyword - also known as 'trust me bro'. Static linking directly to Rust source means it is checked by compiler so there is no need for unsafe.

ripgrep is one of the best grep replacement you can find, maybe even the best, and also one of the most famous Rust projects.

I don't know of a sed equivalent, but I guess that would be easy to implement as Rust has good regex support (see ripgrep), and 90%+ of sed usage is search-and-replace. The other commands don't look hard to implement and because they are not used as much, optimizing these is less of a priority.

I don't know about awk, it is a full programming language, but I guess it is far from an impossible task to implement.

Now the real hard part is making a true, bug-for-bug compatible replacement of the GNU version of these tools, but while good to have, it is not strictly necessary. For example, Busybox is very popular, maybe even more so than GNU in terms of number of devices, and it has its own (likely simplified) version of grep, sed and awk.

What would be the point?

Common Crawl delivers the data as bz2. Indeed I store intermediate data in zstd with ZFS.

That assumes you're processing the data more than once.

bzip2 (particularly parallel implementations thereof) are already relatively competitive for compression. The decompression time is where it lags behind because lz77 based algorithms can be incredibly fast at decompression.

It's blazingly fast

This makes a lot of sense to me, though I don’t know the official answer so I’m just sort of guessing along too.

Linked from the article is another on how they used c2rust to do the initial translation.

https://trifectatech.org/blog/translating-bzip2-with-c2rust/

For our purposes, it points out places where the code isn’t very optimal because the C code has no guarantees on the ranges of variables, etc.

It also points out a lot of people just use ‘int’ even when the number will never be very big.

But with the proper type the Rust compiler can decide to do something else if it will perform better.

So I suspect your idea that it allows unlocking better optimizations though more knowledge is probably the right answer.

Ergonomics of using the right data structures and algorithms can also play a big role. In C, everything beyond a basic array is too much hassle.

Popcount, clz, and ctz are provided as nonstandard functions in GCC (and clang might also support them in GNU mode, but I don't know for sure). PDEP and PEXT do not seem to be, but I think they should be (and PEXT is something that INTERCAL already had, anyways) (although PDEP and PEXP can be used with -mbmi2 on x86, but are not available for general use). The MOR and MXOR of MMIX are also something that I would want to be available as built-in functions.

Thank you, precisely what I had in mind! Somehow I missed this project. As well as Holo[1] (routing)

[1] https://github.com/holo-routing/holo

Is that domain actually about memory safety or about Rust?

Nothing against Ada, it's a good language. The only problem would be finding contributors in that case.

Feel free to enlighten future readers?