I can list a few reasons without pondering too much about it:

1. Rust is gaining much acclaim for writing safer code, a good package management system, a very friendly community and other things. So it's natural that people would be interested in knowing more about libraries, frameworks and tools that would allow them to use Rust for whatever they're working on now or plan to work on soon. Not many people would want to develop their own HTTP handlers or image decoders or message queues or anything else just so they could write their primary project in Rust and gain the advantages it provides. Libraries are a huge part of that bridge that people need to use a language more (one big reason why Python is preferred across different subjects is because of the libraries).

2. This could inspire someone to go to these or other repositories and contribute to them.

3. Considering that images (and JavaScript) make the bulk of web pages nowadays, I'm sure many people would want to know about pure-rust libraries that handle images so that they could now have their web backend projects use more of Rust with better guarantees on a few aspects (like stability of execution, for one). Outside of web, this could also appeal to people who write imaging related applications.

> Considering that images (and JavaScript) make the bulk of web pages nowadays, I'm sure many people would want to know about pure-rust libraries that handle images

Yes, but wouldn't those people want libraries that focus on images, as opposed to libraries that focus on games? (Piston is a game engine).

Piston uses a bunch of pure-Rust image handling libraries. It just integrates them for use in games.

Rust and Cargo promotes a high degree of modularity and thus re-usability. While the image library is being hosted under the Piston project's GitHub profile, the image library has nothing to do with a game engine. Piston's image library is being used in Servo, for example. Rust has created an ideal open source ecosystem.

In the context of Piston being pure rust matters a lot: rust as a really good multi-plateform support and it's way easier to cross-compile project that are full-rust than projects that are Rust with additional C libraries.

In the context of image-processing libraries, which are often used in a web-facing environment, being written in Rust with almost no unsafe code is also a major improvement in term of security.

> it's not a miracle drug.

I agree with you, but I don't think anybody pretends it either.

Rust is a massive improvement over the state of the art in system programming. It's not a panacea, and I'm not going to rewrite all my web or mobile code in Rust, but I'm still really happy Rust exists.

Projects like this one, or the recent announcement that librsvg is replacing C code with Rust one, give me hope that will see fewer and fewer memory-related security bugs in the future, and it's about time !

C image libraries likr imagemagick are full of dangerous bugs. Using a performant memory safe language for image parsing and manipulation is a big win for security (and stability).

If this image handling can be extracted into its own library ( maybe it already has), then it can be used by other projects, and maybe even by C and C++ projects.

For example, https://imagetragick.com/

"One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images."

(FWIW, I don't think any of those bugs are directly addressed by Rust's memory safety guarantee, since they mostly seem to be string injection problems. The strong abstraction power of Rust versus C may help people create APIs that are more resistant, but people can always write bad code. And of course, those are unlikely to be the only bugs in that C code.)

Unfortunately, these bugs will not be prevented by using rust as they are not memory related bugs.

If you code a command that reads and then deletes a file on the command line and people allow remote users to invoke that command remotely, the programming language is not going to help you.

ImageMagick doesn't have the design that is necessary to be exposed to remote users. So it shouldn't be.

> we are chasing more after trends than the fashion industry.

Larry Ellison made the same observation many years ago:

> The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. I can't think of anything that isn't cloud computing with all of these announcements. The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?

A similar sentiment by Alan Kay: programming is a pop culture.

I usually don't agree with these sentiments, personally, or at least not with the implications that are usually drawn from them. But it is something worth thinking about.

i am not sure i would use Larry Ellison as a gauge...

This kind of thing validates one of the premises of Rust: that we can re-write fundamental libraries in a safer language. Demonstrating that it's possible in practice rather than theory is important to lots of people.

A lot of Rust stories _dont_ get upvoted on hacker news as well.

> I want to like rust and understand that there are benefits to it, but why is this on the frontpage?

Because it indicates that there were no edge cases that rust couldn't handle, at least for this project. It's nice to know that it's a suitable tool for 100% of a project and not just 95% like so many others.

Not sure if you are saying that "we" shouldn't be rewriting libraries or "we" shouldn't be upvoting Rust posts. Seems like you are muddling the two.

> I think we need to step back and realise that while there might be benefits to a certain technology, it's not a miracle drug.

Can you clarify what you mean by this? Which rock solid C libraries are there for working with images? I'm not talking libpng and libjepg but higher level stuff. Because most people do not use those libraries directly because they are too low level. So any higher level library is a welcome addition.

Most programming languages currently have some agreed upon image library (like PIL/Pillow in Python) and they are not standing on good foundations either.

i don't know much about image libraries, but this is kinda the point. This is just a blog post that announces the replacement of a c-implementation with a rust one and i don't know why. There might be a good reason, but not in this blog post.

I don't have anything against rust and i would read a blogpost that details what they gain from switching to a rust-based library. But i am a bit frustrated by my subjective perception that recently there were a lot of posts on the frontpage that just do something in a fancy language.

Didn't upvote this post, but I gather that people are excited that there's an alternative to C and C++ that finally seems to have some traction. This isn't the usual "I wrote a more ergonomic version of a library in a language that I happen to like better", it's "I wrote a memory-safe version of a library in a language that might be a plausible alternative to the languages that underpin all of our computing infrastructure".