https://github.com/KillingSpark/zstd-rs
And better yet if they compared it explicitly in their “why” section. As it is, I’m left guessing.
> Why though?
> Using zstd in Rust is already supported via the zstd crate, so why bother with a whole new implementation?
Separately, I'd say their end goal seems to be replacing the C library dependency in Rust's zstd-rs:
> We have our own fork of the zstd that uses libzstd-rs-sys instead of the C library. We'd like to upstream this at some point.
I wanted to like Rust, but I was using unsafe code for performance and such anyway that it made more sense to switch to C.
If you're counting KBs and you have to include zstd yourself (a reverse proxy isn't handling it for you) does that mean you're targeting an embedded device? Are you supporting TLS at that size?
Typically the suggested way to use it is to obtain "bad" rust directly from it (but which still works etc), and then make that "bad" rust more idiomatic. I don't remember any publicly visible success stories for this though. The current Bun rewrite is arguably of this form, but not exactly a "success story" in producing idiomatic, safe rust. Other large rewrites that were well-publicized/docoument, e.g. the fish shell from c++ -> Rust, took a different approach (factor into modules/rewrite each module by hand).
