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

[smitty3268]

I'm glad that you understand all of that. Do you think recent graduates will? Rust started out in large part because of noobs crying about unintuitive C/C++ punctuation and the ability to do a lot of things on one line. Can you see how that's going to be every bit as write-only? Because you need to be able to or you're going to write unmaintainable code.

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.

[hasnoidea]

Granted there are four or five main points of Rust, depending on who you ask, but readability without having to understand 95 different kinds of arcane syntax was definitely supposed to be one of them. And they've failed horribly on that front. Advanced Rust is no more readable to a noob (yes, recent grads are noobs) than advanced C. You could even argue it's less so except for the extreme asterisk abuse C perpetrates.

Sure, the other aspects of Rust have merit but it's not even a tiny bit better than C on producing maintainable code. For any non-basic code, unless you wrote it or have your expert badge, it's effectively every bit as write-only as C.

Yes, a very long time Perl fan is actually going off on other languages about being write-only. The irony is not lost on me.

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

[lowflyer]

Emptied the first box of popcorn after just three pages ...

This thread quickly degraded into a "who has the worse programming language" rant. Isn't this like comparing assholes?

I had a thought crossing my mind: "Perhaps I should develop an easy maintainable PNG library in C++ myself. Just to raise the level of the conversation."

... next box of popcorn.

[iustinp]

There's nothing more ugly than rustards language syntax.

Let's see, you're still pissed off you don't understand the syntax?

[jacob]

Where?



They're only faster, because support the latest optimizations. Performance of C solutions can be the fastest.

That's a very uninformed statement. There is nothing about C that makes it inherently the fastest. In fact it has a number of built-in inefficiencies. Null-terminated strings are one, although they presumably don't play any role in picture decoding. But C is also very biased towards base+offset addressing, which was great on the PDP-11 architecture but not so much on current CPUs. It doesn't really have any pointer aliasing rules to speak of, which on one hand prevents entire families of optimisations including deconstructing certain types, and on the other hand it can easily become a problem to optimise when dealing with matrices (or any other kind of multi-dimensional array), for which C doesn't have native support either. That's obviously highly relevant for picture processing. C's weak typing means that types generally can't have niche values, etc. Long story short, there is a reason why Fortran is still widely used for HPC: it outperforms C. As for Rust, it was designed based on many (really many) lessons learned from C and has largely avoided the same pitfalls. It has its own tradeoffs: for example fat pointers have both advantages and disadvantages, one disadvantage is that they basically boil down to two CPU registers instead of one which can negatively impact performance if too many are used at the same time (but that's very rarely the case, especially in Rust). Rust is also still not taking full advantage of its borrow checker in terms of performance optimisation, simply because the LLVM back-end is not there yet, although progress is being made. But on another note, Rust is very friendly towards parallelisation while C basically does nothing at all in that regard. Writing a multithreaded program in Rust that outperforms an idiomatic, single threaded C version by 50-100% is very easy, far easier than trying to parallelise C code with varying results.

[DavidBrown]

Where is the argument about superior compiler flags like -O3, -march=native and millions of others? Oh yes, sometimes they introduce bugs because of undefined behavior and other marvels of C that make bad software even worse. And in 2024 we are still compiling software with -O2 and afraid to even use -v3 architecture subset in production which is already 10 years old.

Baring compiler bugs (which do happen, but incorrect code generation bugs are rare and usually quickly fixed), compiler flags do not introduce bugs in code - but they can expose bugs in code. That is a huge difference.

People who are familiar with compilers and optimisation will generally use -O2 rather than -O3 because -O3 can take a lot more build time while usually giving very little speed gain. And for some code, it can even slow down the result (typically as a result of larger code size leading to cache misses).

I wonder why nobody wrote a new library with latest optimizations and without technical debt in C. Oh yes, because they can't and probably nobody can do that. Google even decided that it is simpler to create a new specific language for decoders to write a library just to avoid using great and marvelous C directly.

No, it is not because nobody can do it - it is because nobody has been motivated to do it. Writing a new PNG decoder library is a fairly thankless task. It's not something that is likely to appeal much to people for fun, and it's not likely that a company will see much financial reason to pay people to write it. However, the current bunch of Rust fanatics (as distinct from people who simple use Rust as a good choice of language to do their work) are motivated to do such re-writes so that they can "prove" that Rust is faster than C.

The reality, of course, is that this is total nonsense. There is pretty much nothing that can be written in Rust that could not be written in reasonable C with faster results - and that is especially true if you hold to safe Rust. The point of Rust, sticking to reality rather than either pro-Rust or anti-Rust fanaticism, is that you can be more expressive than C, have many (but far from all) of the higher level features of C++ with a nicer syntax, and significantly reduce a major class of programming errors without too much run-time overhead compared to C. Rust is not faster than C - it is merely intended to be efficient enough that it is a realistic choice (compared to C) for many tasks. (This is a little like C being intended to be efficient enough that it can be used instead of assembly for most tasks.)

The same people that wrote a blank sheet faster PNG decoder in Rust could almost certainly have written an even faster PNG decoder in C (or C++, for that matter). It's the full re-write with newer algorithms, newer methodologies, and with a view to newer processors than makes the difference, not the language.

You surely know such a language, you don't mind sharing with everyone? I wonder what language saves from constructs like if (true) { exit(1); } (where true is of course some result of complex long computation task).

I can't speak for other posters, but I can tell you that people can write good and bad code in any language. The language is a minor concern for code quality, assuming the language is a reasonable choice for the task. Code quality - correctness, efficiency, flexibility, etc., - comes down to developer ability and training, and development processes. Good understanding of algorithms trumps language choice every time. Good knowledge of the target processors and use of their accelerators beats language choice at the low level. Good coding standards, code reviews, tools, and testing methodologies beat fancy language features for code correctness.

[Volta]

Let's see, you're still pissed off you don't understand the syntax?

I'm pissed off at rustards foundation. When comes to syntax it's the ugliest one I've ever seen. Language itself may be good, but mentioned things are rather unfixable.

[dragon321]

There's nothing more ugly than rustards language syntax.

Have you ever used C++?

[ssokolow]

However, the current bunch of Rust fanatics (as distinct from people who simple use Rust as a good choice of language to do their work) are motivated to do such re-writes so that they can "prove" that Rust is faster than C.

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.

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.

(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.

[TheMightyBuzzard]

I disagree. I remember when I was a Rust noob and a C noob (and I learned C beyond one semester of Hello, World! after Rust) and I found Rust at least as easy, if not easier, to pick up.

Plus, one of the important things to keep in mind is that, generally speaking, you don't need to use all of the features. While you ramp up your skills, you can accomplish a lot while leaving most of that hidden inside the seemingly magic API designs that more experienced devs are coming up with. (One of the authors of The Rust Book has said that he only needed to write a macro once.)

Hell, that's one of the recurring themes in advice on how to learn/teach Rust. Don't let "make costs explicit" lure you into trying to dive head-first into the deep-end.

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.