dljfield.com

A shockingly long time back, given how little I have written, I put my first post up on this blog, which discussed issues surrounding open source in JavaScript. At the time, the issue was around a package called event-stream, but I mentioned in passing a previous issue where a package had been removed from the NPM registry and blown the whole creaking mess of transitive dependencies that is JavaScript development right up.

This past week a similar thing has happened in the Rust community, though on perhaps a less damaging scale.

Now, I should point out up front that I am not a part of the Rust community, and have never used Rust, though I am interested in it from afar.

That disclaimer aside, the issue this time was that the Actix web project was removed from the world due to drama around the author’s use of unsafe blocks.

The reasons for the author’s decision are interesting, and naturally it has led, once again, to a discussion around how people conduct themselves in open source, and what things are expected of maintainers.

But from my point of view it just looks remarkably similar to the issues that I talked about with open source in JavaScript. People are using packages in production, offered by single maintainers, and are doing so due to a lack of a standard package or feature for some commonly needed functionality.

Now, Rust is aimed at a much lower-level than JavaScript, and it is not entirely unreasonable to say that it doesn’t really need a standard library HTTP client given what it’s supposed to be doing. However, the effect here is ultimately the same, and the nature of the open source community in Rust perhaps has some of the same issues as the one in JavaScript—indeed, perhaps in open source generally at this point.

An article—well worth reading—that was at least part of the back-breaking straw leading to this, talking about soundness, brings up some interesting and related points. There are a lot of HTTP clients in Rust, many of them built on the same underlying dependencies and attempting to do the same things, but each with small or single-person teams and none of them complete. The author’s conclusion is that there is not even one library suitable to use in production, and he then wonders why those maintainers are not just working together on a single project.

And this is my opinion as well. Yes, it can be argued here that an HTTP client/server is not an appropriate feature for Rust to be including in its standard libraries. However, if that is the case then the packages available to the community need to be built to really work, by a large and active team.

Rust is aiming to be a serious player, making native development safer and faster, correcting the mistakes of the past. That goal is, to my mind, entirely laudable, but it will ultimately be undermined if the mistakes of open source in other communities are also not learned from and corrected. There is no point in Rust if huge amounts of it just ends up the same as JavaScript: that creaking mess of transitive dependencies that can go away at any moment.