It has been a while since my last post, so I figured I just picked up a topic that has been around my mind lately.
After I ported the RSVG Pixbuf Loader to Rust (although I gave up the meson-fu to Federico and Bilal) I decided that maybe I should give a try at porting the WebP Pixbuf Loader.
webp-pixbuf-loader is probably the only FOSS project I have started on my own that I have managed to maintain in the long run without orphaning or giving it up to someone else. I wrote it out of curiosity and it turns out plenty of people find it rather useful as webp is pretty popular for storing comic book backups and other media.
The WebP Pixbuf Loader is relatively small although ever since animation support was contributed it grew quite a bit. I’ve been handling a couple of issues ranging from endianness to memory leaks, I thought it was probably worth the while to give it some Rusty love.
Porting the static image support was relatively quick, there’s, but it took me a while to understand how animation works in GDK-Pixbuf as the original animation support in C was contributed by alanhaw.
I suspect I am prolly the first person to use the GdkPixbufLoader APIs to implement a new pixbuf loader, I had request a few fixes upstream, kudos to Sebastian Dröge and Bilal for handling those swiftly and shipping them in the last release.
Anyhow, last month I finally made it all work:
Now comes the hesitation part, regardless of integrating the former tests in the build system (Cargo is great at embedded unit testing but meson is better at running an integration test plan), my main gripe is that it turns out that there’s quite a few people packaging this, not just for Linux distros but also BSDs, Illumos, Windows and brew/macOS…
I really don’t know what the impact would be for anyone packaging outside of the Linux world, I have a few CI pipelines for Windows but obviously I am about to break them if I switch.
I am pondering the idea of releasing a bunch of beta releases and hoping package maintainers will start taking notice that I’m moving on, but I am trying to be mindful of how much time they need to sink for the Rust move to happen and weight that against the net benefit.
The other part that makes me hesitate over flipping the switch is the measure of the overall benefit. Sure Rust is nicer to maintain, but it still is a small codebase, Rust adds a bunch of runtime dependencies (bindings) and it is not clear to me how healthy the webp bindings are going to be long term, there are two similarly named bindings one has more frequent releases and the other is more complete which is annoying. These bindings bring an issue of size: the Rust port is 4MB in size vs. 76KB for the C implementation.
Not sure what to do, feel free to add your thoughts in the comment section.
UPDATE: It looks like the size issue can be addressed and total size drops down to ~300KB by using the right flags.
5 thoughts on “Dilemma’s in Rust Land: porting a GNOME library to Rust”
Ignoring the q. about packagers, have you looked at reducing the size of the Rust binary ? I found https://github.com/johnthagen/min-sized-rust a useful guide … there are usually some easy wins if you haven’t already dug into this
Yeah, several people pointed it out. I have added a comment.
IMHO, stick to the C version (i.e., declare your Rust port a fun experiment, add a readme link sending any users to the original C code, and close the -rs repo). The C code works, is more than 50 times smaller, and way easier to package.
I think this should serve as a lesson that porting working C code to Rust is not a good idea, no matter how tempting.
Rust is future. In my opinion we should use it more often even this bring big executable.
About the size, I suggest you have a look at
LikeLiked by 1 person