That is an absolutely massive amount of unsafe, is the plan to reduce it over time? The benefits of the Rust build system are reason alone to use this (as a direct competitor to the C version), but claims about memory safety are suspect no matter how confident the authors are about correctness.
they're using c2rust. It transpiles c -> rust "directly", e.g. ints map to libc::c_int, pointers map to pointers, array access map to dereferencing pointers at an offset, etc.
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).
I was using the original zstd rust crate for my web app, but I couldn't get my module any smaller than 150kb, but when I switched to C for web app I was able to do a whole lot of optimizing and culling until I got it down to 39kb.
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?
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.
reply