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

[rabcor]

Of course a library that's nearly 30 years old and used widely in production is going to be slower and have more CVEs than a rarely used relatively new library which can avoid 30 years of technical debt and target modern hardware.

Rust won't save you from logic failures or stupid developers.

Rust is supposed to be like c++ but with training wheels for imbeciles. Competent c++ devs tend not to like it because it's not actually in any meaningful way better than c ++ for competent devs. But getting to that level takes a lot of time which makes rust attractive for lazy scrubs and fresh faced devs.

C when correctly utilized should be faster than both of these, however as you said, 30 years of technical debt and 30 year old code that was made before the days of multithreading.

[amxfonseca]

Lets talk again in a few years when someone has to maintain this ...

image.png

There is nothing to maintain, since that simple function just does a GET request and returns the parsed JSON response. Couldn't be any simpler, although in reality most people would go with a simpler and less verbose approach.
It is syntax heavy, and touches a lot of different concepts. So it helps if you learn them first (async, generics, lifetimes, type/trait narrowing, Results and dynamic dispatch).

If you had to implement equivalent functionality in C, you would end up with hundreds of lines of even more unreadable code, that would be a pain to maintain since day one.

You would have to rely on threads to make it non-blocking (note the async keyword), write a bunch of error handling code between each statement (note the ?) and handle the parsing of the JSON response yourself, forcing most of types in your code to be a bunch of `void *` and hoping for the best.

It is actually impressive how a function that does this much can be so simple. Not too long ago this was only possible with interpreted/JIT languages with plenty of runtime overhead (although C++ can cover most of the functionality seen above, and it will look even more unreadable). It just shows how powerful Rust (or any other modern languages) are.

That resulting binary will have zero overhead compared to any alternative implementation in C. The only thing left for runtime is the dynamic dispatch on the Error, but that was an explicit decision by the programmer to return the original errors. Compilers can't optimise what they don't know about, but in this case the overhead is negligible.

Anyway, that code snippet is a bit of a meme. It was written by someone trying to prove a point that was never there, so they would have something to complain about.

I can also go to the Linux kernel code, and post some of the macro voodoo stuff that developers need to rely on to make the code minimally generic. No programmer can decipher that, unless they read the documentation first.

[Veerappan]

I can tell you are not a programmer, at least not an old school one when programmers weren't being churned out by the millions by these half-assed tech schools like DeVry.

There was a time programmers made extensive use of assembler and didn't rely on a compiler to auto vectorize a thing, they hand optimized their code.

Today you have people with the equivalent skill level of a high school kid writing code using generic algorithms hoping that some programmer more talented than them writes a compiler that will make them look like they know what they are doing.

You weren't replying to me, but this has a bit of a ring of the No True Scotsman fallacy to me.

I've been programming professionally for 20+ years, and wrote my first lines of code another 10 years before that (~13 years old). I've written in basic, cobol, fortran, x86/arm assembly, C, C++, OpenCL, and many others. I've spent months hand-optimizing OpenCL kernels for GPU execution to try to extract every last ounce of performance from a video decoding library.

That said, my day job pays me to write in java/html/javascript. While I *can* hand-optimize code for execution on multiple different architectures, if the compiler can auto-vectorize my code and do a decent job of it, I will let it handle that. If there's general improvements that I can make to my data structures/algorithms to make the compiler more able to vectorize, great. But spending all of my time hand-optimizing SSE/AVX/etc is not a good use of my time or my employer's money unless there's a performance-critical path that the compiler is choking on.

If the compiler can produce fairly well optimized code, let it. When the compiler can handle that stuff, it frees up our time to handle larger and more complex issues and overall algorithm/structure refactors (as well as the ever-important new features everyone wants).

[amxfonseca]

I can tell you are not a programmer, at least not an old school one when programmers weren't being churned out by the millions by these half-assed tech schools like DeVry.

You would be wrong! At least partially right on the old-school part, I am not and do not have a desire to be. It is called choice.

There was a time programmers made extensive use of assembler and didn't rely on a compiler to auto vectorize a thing, they hand optimized their code.

Still do, when needed and the compiler can't do the job for you. When it does, I like to spend the extra time writing tests, documentation and tackling tech-debt.

You must be the one shouting at the cashier because they rely on the barcode scanner instead of typing everything by hand. Wish we had those old school cashiers again!

Today you have people with the equivalent skill level of a high school kid writing code using generic algorithms hoping that some programmer more talented than them writes a compiler that will make them look like they know what they are doing.

Both are equally important. Some people are great at crafting high quality hammers and chisels, while others are great at using those same tools to sculpt their own masterpieces.

And there is a third group that likes to point out that a proper artist will always forge his own tools. Those people usually can't do either!

[bacteriamanicure]

Rust is supposed to be like c++ but with training wheels for imbeciles. Competent c++ devs tend not to like it because it's not actually in any meaningful way better than c ++ for competent devs. But getting to that level takes a lot of time which makes rust attractive for lazy scrubs and fresh faced devs.

This post sponsored by whatever government you don't want hacking into your garbage.

[sophisticles]

Actually opposite. Any big rust project comparable to Linux or PostgreSQL? Not even close!

Redox, COSMIC, ring a bell?

[sophisticles]

Observed result (aka reality):
- Compiler produces faster code than superior elite developers.

Where do you think compilers come from?

[sophisticles]

There's no way you think that's unreadable. Do you program at all? I've written way worse stuff in JavaScript than that snippet.

That just means you are a lousy programmer.

Not something to be proud of.

[sophisticles]

And it is the semantic part of future languages that are going to enable compilers to optimize to such a degree that no human can compete.

Who do you think is writing the compilers?

[cb88]

Rust is supposed to be like c++ but with training wheels for imbeciles. Competent c++ devs tend not to like it because it's not actually in any meaningful way better than c ++ for competent devs. But getting to that level takes a lot of time which makes rust attractive for lazy scrubs and fresh faced devs.

C when correctly utilized should be faster than both of these, however as you said, 30 years of technical debt and 30 year old code that was made before the days of multithreading.

Rust is nothing like C++, correct use of C++ is undefined.

Abort, Retry, Fail?