Asking for a friend - could someone explain what happened there? The README doc is quite vague - it is more of a personal justification than a rationale (to me).
Sounds like the maintainer writes a lot of code using rust's "unsafe" keyword, and regularly gets issues raised about this (and versioning, and some other bits).
This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.
Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.
It's not coding style, it's refusing to investigate use-after-free vulnerabilities in code because it's "boring". Noone should care if a maintainer uses tabs or spaces, or has weird variable naming, but if "coding-style" leads to security issues (due to hand-rolling unsafe memory-primitives), then it is an actual issue, especially if it's for a popular web-framework.
Don't like it, don't use it doesn't really apply to security vulnerabilities in such major packages.
Flaming and personal attacks are not the solution to this stuff, but this drama feels somewhat self-inflicted.
"Don't like it, don't use it" applies in all situations where the code is free to you and you didn't enter into a contract to "correct" those things that you don't like. People were always free to fork the code and fix what they don't like.
Yes, the maintainer could have made his reasons for making the project more clear, and the maintainer could have been more clear on the intended use of the project (not for production, personal project to see how fast Rust can be, etc). There are a lot of things the maintainer could have done.
However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.
For future maintainers of projects, please do yourself a favor and clearly state the intentions of your project. Is it for production use or just a personal project to see how far you can take an idea? Make it clear and get into the habit of reminding people of the project's goals. I am very grateful for projects that do that since it helps me save a ton of time for both the maintainers and myself.
There seems to be a mismatch between the maintainer's expectations of the project and the community's expectations. It's unfortunate that the author decided to pull it, but hopefully this is a lesson to the community to make sure a project is a good fit before diving in with suggestions.
> However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.
Should people wait until credit-card data or PII is leaked due to security vulnerabilities? The problem with security is that it impacts more than just the programmers using the framework, it impacts everyone. Does the author deserve the nastiness? No. Do security issues need to be reported, and if not fixed, called out? Yes, for big and advertised projects issues like that need to be reported. If not, there will be users that would naively expect the web-framework they're using to be somewhat secure.
The framework had a professional looking website advertising the project, it had good documentation, a user-friendly API. It advertised a actix open-source community. Had over a million downloads. I would say that expecting actix to be run like a somewhat professional project is not a strange assumption.
The way it was called out was pretty terrible though, and I doubt anyone is happy with what happened.
If personal info or CC data gets leaked, the company which used this library/framework will be found legally liable. Using random code from github is not a valid product development strategy.
The author can write their entire code in an unsafe block for all they care. The buck stops with those that use the framework and that is made quite clear in the license.
Is it a community run project or not? The website seems to imply that the community is welcome to participate: "We're a welcoming community so don't be afraid to engage."
There is no such thing as a community run project. But either way, people told the author to literally stop writing Rust code because he doesn't respect semver. This is not a participation, this is just hate.
The issue was triggered by someone executing a benchmark on http crates and opening an issue on github, that was then deleted after some heated back and forth.
Wow. Talk about a bad response though. No matter how abused you may feel as the sole maintainer you should still not throw a tantrum. Censoring an issue title, body, and comments is a gross overreaction. If you want to throw in the towel then just throw in the towel.
It seems like the overarching issue is that Rust is a house of cards. They added unsafe like Java has null. My favorite part is that you can declare a crate to forbid unsafe, but that then doesn't have to hold for it's dependencies.
The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
> The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.
That would mean everything is unsafe, since every crate depends on core (or on std which depends on core), which has "unsafe" code.
The design of "unsafe" in Rust, instead, is to allow building safe abstractions on top of unsafe code (or be able to clearly mark when the abstraction itself is unsafe). That way, for instance, users of `Vec::push` do not have to worry that it uses uninitialized memory (which is unsafe).
This is a poor comment. You clearly don't understand how unsafe is to be used. No code (of significant size) that you run will be bug free ever. So you might as well start from that assumption and realize you are trying to minimize the amount of unsafe code and bugs; you will never remove all of them no matter what the language.
Using unsafe doesnt necessarily mean you will have undefined behaviour, it just means you have to think really hard about the behaviour because the compiler won't have your back.
I wish there was a better way of handling that in Rust. You should be able to have a few markers in your code:
- uses unsafe
- no unsafe, but dependencies may use unsafe
- no unsafe, no dependencies except the standard library may use unsafe
- no unsafe, not even in the standard library uses
The current situation is the second one, but many cases probably want the third, and occasionally the fourth.
The best part is, this should be fairly easily solved by crates.io upon submission (is there any use of unsafe and are all dependencies marked as strict or more strictly than yours?).
This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.
Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.