[LinusU]

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

[restalis]

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

Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me.

¹ ...and not only. I've already described in other comments some of the issues I see with it as a software development tool, here https://news.ycombinator.com/item?id=31565024 here https://news.ycombinator.com/item?id=33390634 and here https://news.ycombinator.com/item?id=42241516

[LinusU]

> Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays.

Makes sense, and I'd probably make the same call if I was a maintainer and someone submitted a patch which increased performance at the cost of maintainability...

> Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me.

Here I have to personally disagree. I think that Rust is easier than both C and C++. Especially when coming into an already existing project.

The chance of me contributing to a Rust project is higher than to a C project, because I feel more comfortable in knowing that my code is "correct". It's also easier to match the "style" since most Rust projects follow the same structures and patterns, whereas in C it can vary wildly.

E.g. I contributed my first feature to Valkey (Redis fork, C codebase) recently, and figuring out how the tests worked took me quite some time. In fact, in the end I couldn't figure out how to run a specific test so I just ran all tests and grepped the output for my test name. But the tests take tens of minutes to run so this was sub-optimal. On the other hand, 99% of all Rust projects use `cargo test`, and to run a single test I can just click the play button in my editor (Zed) that shows up next to the test (or `cargo test "testname"`).

(with this said, I think that Valkey is a really well structured code base! Great work on their part)

Anyhow, this is just to illustrate my experience. I'm sure that for someone more used to C or C++ they would be more productive in that. And I could go on for ages on all the features that make me miss Rust every day at work when I have to work in other languages, especially algebraic data types!

[moomin]

This is where Rust is going to win out. The significantly larger standard library increases the number of legible improvements one can make.