Rust-Based, Memory-Safe PNG Decoders "Vastly Outperform" C-Based PNG Libraries

[TheMightyBuzzard]

Honestly, yes. It's fairly trivial and much of the concepts will align with other languages they've learned, other than perhaps the lifetime management bits.

Every new graduate is familiar with async/await stuff because they learn javascript, generics/interfaces should be familiar from Java, C#, or Typescript, and learning that adding a ? gives you error handling is trivial. Box is simpler than learning new or malloc + memcopy.

That code snippet has a bunch of unfamiliar looking syntax in it for a C developer, which I think is the point. But anyone who's spent a week learning Rust could glance at it and instantly understand it with no problems, because it's just simple syntax stuff. No complex logic. A corresponding sample in C would be far harder to parse through because it would have so much boilerplate error handling/setup/etc. obscuring the real code.

I will say being able to properly design a good Rust library API is more complex than one in C because you need to take into account a lot more about how it will be getting used, whereas in another language you can just do anything you want and then document it all. But that's not something a new graduate should be doing anyway. Using it and understanding what an existing method does is simple.

Brother, I've been coding Rust since it was still shiny and new and I still had to give that more than a glance to understand all aspects of it. And if you think it's not going to be a new grad tasked with coming along later and maintaining something the original writers are no longer available for just because it wasn't a new grad who wrote it, you are living in fantasy land.

[TheMightyBuzzard]

Idk where you live that your graduates are "noobs". But sounds like you should start a school yourself then.

Earth. What planet do you live on where recent grads can tell their ass from a hole in the ground fresh out of school? Oh, wait, are you a recent grad yourself and think you know everything? Or anything for that matter?

[ssokolow]

That's kind of the point. If someone else uses features you weren't taught all over the place, they've written write-only code.

First, I didn't say you never learn them. I'm saying that any language (except maybe Go, given it tries to be primitive so the learning process is short) has a learning curve. I don't see you criticizing Python, yet most people (myself included) have never needed to get into the kind of metaclass hackery that allows what gets instantiated by Django ORM to be different from what you write.

(And yes, metaclasses are a Python language construct, not just a design pattern. They're an extension of the Python type system that are to classes as classes are to instances. I'm not sure whether it's a more C++-ish or Haskell-ish idea.)

Second, as with Django ORM, most people aren't writing or maintaining the next Serde. I've never implemented a "tt muncher" in Rust's declarative macro system because I've never needed to... just like the overwhelming majority of people.

[DavidBrown]

It's been my experience that these rewrites aren't to prove anything but, rather, to escape the hassle of integrating with C's (lack of a) build system.

That is not a motivation for re-writing the PNG libraries (or any other existing code). It might be a motivation for choosing Rust as the language for a re-write, but not for doing the re-write in the first place.

C does not have a build tool - it works with any build tool. Similarly, it has no package manager, or centralised library repository. This makes things flexible, and you can make your own choices about how to handle things. But also inconsistent and people do lots re-invention of wheels. But it is a poor C programmer who can't write at least a very simple makefile and type "make" for their build. Bigger projects will, naturally, require more effort in their build tools - but that is no different for Rust or any other language. After all, your tools should handle things well beyond just the language - you need to work with testing, deployment, "linting", documentation generation, and many other features.

If you have a pure Rust codebase, for example, you can statically link musl-libc instead of dynamically linking glibc for non-cross-compiling Linux builds (i.e. achieve a Go-like result for deployment to Linux on the same ISA) just by rustup target add-ing a musl-libc target and then specifying it via --target when invoking cargo build or cargo run.

I don't follow this - there is no problem statically linking C code to musl-libc if that's what you want to do.

(The convenience of Rust's tooling is actually one of the things I saw C and C++ devs commenting on most when coming over to Rust, and it's also the inspiration for the least bad of the build/dependency management systems currently available for Python.)

...so, basically, the exact same reason the Go ecosystem is NIH-ing the world except that Rust has a whole ecosystem (1, 2) of tooling for exposing bindings to Rust libraries for non-Rust languages and Rust is also more suited for compiling to WebAssembly than Go is.

I don't know the Rust tools well, so things I say here might not be accurate.

What I can say for sure, however, is that there is no one-size-fits-all for tooling. Look at package management, for example. For some kinds of development, you want to be able to get the latest versions of libraries quickly and easily - often you want to pull in fixes to packages as soon as you can. (You'd also want to use dynamic linking for libraries whenever possible.) But for other kinds of development, that's the last thing you would consider - you want everything to be as static and fixed as you possible.

So as I see it, there is no single "correct" philosophy here. Standardising tools will be good for some people and bad for others. For every C or C++ developer who says they wish C++ had something like "cargo", there will be another one saying they are glad C++ does not push anyone into a standardised package management tool and a third who says they wish there was a standardised C++ package tool but it should work in a completely different manner from "cargo".

[ssokolow]

That is not a motivation for re-writing the PNG libraries (or any other existing code). It might be a motivation for choosing Rust as the language for a re-write, but not for doing the re-write in the first place.

C does not have a build tool - it works with any build tool. Similarly, it has no package manager, or centralised library repository. This makes things flexible, and you can make your own choices about how to handle things. But also inconsistent and people do lots re-invention of wheels. But it is a poor C programmer who can't write at least a very simple makefile and type "make" for their build. Bigger projects will, naturally, require more effort in their build tools - but that is no different for Rust or any other language. After all, your tools should handle things well beyond just the language - you need to work with testing, deployment, "linting", documentation generation, and many other features.

It's the sysvinit vs. systemd problem all over again. People are fed up with having to babysit ad-hoc hairballs of shell script (sysvinit), ad-hoc hairballs of bespoke build scripting (C), distro-specific packages or ad-hoc hairballs of "portable" packaging (Flatpak), etc. and have stopped asking for solutions and having their requests ignored and started writing their own replacements.

It's another of those "Don't like it? Then get off your ass and compete! I'm doing something to address my needs, whether or not you like what I'm doing." situations.

I don't follow this - there is no problem statically linking C code to musl-libc if that's what you want to do.

The problem is that, no thanks to the bespoke nature of every package's build scripting, the musl-gcc wrapper is unreliable and something like Docker is really the only reliable way to ensure that all your C dependencies statically link against musl-libc instead of pulling in a dependency on a dynamic link to some system library.

I don't know the Rust tools well, so things I say here might not be accurate.

What I can say for sure, however, is that there is no one-size-fits-all for tooling. Look at package management, for example. For some kinds of development, you want to be able to get the latest versions of libraries quickly and easily - often you want to pull in fixes to packages as soon as you can. (You'd also want to use dynamic linking for libraries whenever possible.) But for other kinds of development, that's the last thing you would consider - you want everything to be as static and fixed as you possible.

So as I see it, there is no single "correct" philosophy here. Standardising tools will be good for some people and bad for others. For every C or C++ developer who says they wish C++ had something like "cargo", there will be another one saying they are glad C++ does not push anyone into a standardised package management tool and a third who says they wish there was a standardised C++ package tool but it should work in a completely different manner from "cargo".

There doesn't have to be (eg. the incorporation of Rust into the Linux kernel doesn't use Cargo)... but there's great value in having a default solution that's well-aligned with common needs.

[sdack]

Another article about something Rust, and again it sets the comments on fire. Again, trying to falsely attribute Rust with being fast. And all it took was for Phoronix to quote a Reddit article. Did people even look past the inflammatory Reddit article? It does not look that way judging by the number of insults and tangents. Just one search for "fast png library" yields me fpng, which is said to be a very fast C++ PNG reader/writer with 23x faster compression and 2.5x-3x faster decompression compared to libpng. Thus, Wuffs claim of being fastest with 1.5x-2.75x when compared to libpng falls short of its claim. The author of fpng even compares to Wuffs PNG with being 10% faster than Wuffs.

[Shnatsel]

Just one search for "fast png library" yields me fpng, which is said to be a very fast C++ PNG reader/writer with 23x faster compression and 2.5x-3x faster decompression compared to libpng. Thus, Wuffs claim of being fastest with 1.5x-2.75x when compared to libpng falls short of its claim.

fpng is a subset of PNG, not a full general-purpose encoder/decoder. It can only decode images it has itself encoded. Its encoding is extremely fast, but sacrifices compression ratio. So it cannot be compared to a general-purpose encoder/decoder.

However! Since we're talking about fpng, it would be remiss of me to mention that the Rust png crate adopted the fpng algorithm in its fast compression mode. So if you use Rust, you get the benefits of fpng transparently, without having to pull down a whole other library and adding a codepath for a whole new API.

And there used to be a fast path for decoding fpng-encoded images in Rust's png crate as well, but it got removed because the general-purpose decoding code is just as fast.

[TheMightyBuzzard]

First, I didn't say you never learn them. I'm saying that any language (except maybe Go, given it tries to be primitive so the learning process is short) has a learning curve. I don't see you criticizing Python, yet most people (myself included) have never needed to get into the kind of metaclass hackery that allows what gets instantiated by Django ORM to be different from what you write.

(And yes, metaclasses are a Python language construct, not just a design pattern. They're an extension of the Python type system that are to classes as classes are to instances. I'm not sure whether it's a more C++-ish or Haskell-ish idea.)

Second, as with Django ORM, most people aren't writing or maintaining the next Serde. I've never implemented a "tt muncher" in Rust's declarative macro system because I've never needed to... just like the overwhelming majority of people.

Criticizing Python is redundant.

As for the rest? There are plenty of ordinary places where obscure arcane trickery isn't strictly needed but the code could significantly benefit from it. In any language. Which is what we're talking about. Strawmaning it off and acting like it only gets done in Rust in libs like Serde is straight bullshit.

[ssokolow]

Criticizing Python is redundant.

As for the rest? There are plenty of ordinary places where obscure arcane trickery isn't strictly needed but the code could significantly benefit from it. In any language. Which is what we're talking about. Strawmaning it off and acting like it only gets done in Rust in libs like Serde is straight bullshit.

I'm saying that Rust isn't special in that regard. Every language has a progression of increasingly more knowledge-requiring constructs, including ones most people will never touch which get used in places like the C++ STL, Django ORM, etc. etc. etc.

[sdack]

... it would be remiss of me to mention that the Rust png crate adopted the fpng algorithm in its fast compression mode. So if you use Rust ...

Rust Rust Rust ... It is again just all about Rust, isn't it? Wuffs PNG exists as C code, too. So the claim is just false, again.