A Sad Day for Rust

> Forking is extremely aggressive

This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one.

I object to the characterization of forking as aggressive first because it's not, and second because it cuts off another potential avenue of redress or action. We already agree that "shouting on twitter and reddit" is not a good response. If you declare forking off limits or "impolite," what alternatives are left in a case like this?

I acknowledge the complicated ecosystem impacts of forking a popular project (I'm from the JS world where the impacts are extreme), but I don't think "let a project stagnate or yell and shout because the maintainer has other priorities" is a better alternative.

Forking a project in a case like this should be seen as "putting your money where your mouth is"/"stepping up to the plate"/taking on responsibility for change if you think a project is going in the wrong direction. Personally, I fault bitter complainers who don't fork a project for being lazy: do you care enough to actually do the maintainer's job, to take on that responsibility? If no, then what gives you the right to condemn them? If yes, great! Your problem is solved and you can maintain rather than complain.

More forks please.

* just as asking someone "where are you from?" can be perceived as aggressive but that doesn't make it objectively/inherently aggressive.

"Denial of decorum attack" is a great description that deserves broader visibility. It's also a pithy summary of Twitter.

What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects?

You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it.

If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not helping, especially when slamming people working for free trying to solve it, even if not correctly or the way you'd like).

Let me point out that even if you think that this project is "not rust-y enough" by violating basic premises of the Rust way, it would still be useful as it outperforms all those C based project with at least as many guarantees than the C versions.

To me the important part is that we as programmers start advertising our intent. If the intent was to learn how Rust works, then we should write that in the description. Instead we write things like "very fast and lightweight framework". To many people fast and lightweight is good enough. Many other people would also like dependability and sustainability. So please, just put a little label on your github project.

All my open source projects, for example, are exploratory. None of them was meant to be used in production unless you tested rigorously that it would work, and that is on you then. There is nothing wrong with that, I think, as long as you communicate it up front.

People are just importing open source libraries with flashy sounding descriptions left and right, and then they find out those were unfinished and crash all the time, or the author ignores bug reports, or will not maintain it anymore, or thinks it's ok to switch the APIs around on you, breaking your ability to upgrade without reworking your application.

Again, there is nothing wrong with that. Just be honest about it up front.

Given the "unsafe guts" most of Rust stdlib contains, there's going to be some baseline of unsafe code that every project has. I could thus see this confusing new authors and users - you could have a project with zero unsafe lines that will still report a relatively large unsafe surface.

Besides, perhaps this would reinforce the notion that unsafe is - by its very nature - a bad thing. To quote Klabnik:

> it turns out actix-web is using a lot of unsafe code. That’s not inherently a problem. The problem is, a lot of that unsafe code is not actually needed.

If the code were actually needed, then there's no benefit in printing this metric - it just makes a project that is using the feature perfectly correctly look bad.