Comment by ealexhudson
5 years ago
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.
The maintainer can choose whatever style they damn well please, if you don't like it don't use it.
What is hard about this?
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.
> it's refusing to investigate use-after-free vulnerabilities
Please investigate yourself, don't ask others to do the work you consider important for you for free.
6 replies →
"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.
> somewhat self-inflicted
Let's not start victim-blaming please.
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.
3 replies →
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.
There's a difference between engaging and putting up with raging users
Civility, apparently.
Some people just never "grow up" and/or learn how to treat people with respect, and developers are not special in that regard.