A Sad Day for Rust - <AUTHOR> https://words.steveklabnik.com/a-sad-day-for-rust <comment><USER3> The earlier related thread is [https://news.ycombinator.com/item?id=22073908](https://news.ycombinator.com/item?id=22073908).

</comment><comment> _-___________-_ I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all.

I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage _his project_ differently. I just didn't see why a library doing what Actix does should use _any unsafe code at all_ , so I didn't use it.

When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision.

There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

<comment><USER4> What do you use now? Warp?

<comment><USER5> Right now, if you want async/await, you either have warp or tide.

Hopefully gotham or rocket gets around to updating.

<comment><USER6> Can anyone comment on how close Rocket is to a 0.5 release? I've been wondering for awhile, but opening an issue to ask seems annoying.

<comment><USER7> I don't have any insight but you can subscribe to this issue to see how things are moving: [https://github.com/SergioBenitez/Rocket/issues/1065](https://github.com/SergioBenitez/Rocket/issues/1065)

</comment></comment></comment></comment></comment><comment><USER8> I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project.

No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.

Of course, you could do neither, but don't be surprised when people call you out on it.

<comment><USER9> > No one expects you to write perfect code, but we do expect you to fix flaws > when you learn about them.

It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right?

Your comment is precisely what entitlement looks like.

<comment><USER10> > It's not like he was getting paid to work on this, was it?

That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely.

Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.

Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.

Open source is like capitalism. But a project's success is measured in commitment instead of capital.

<comment><USER11> I'd argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it.

I think the basic rules still apply: You're getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.

<comment><USER10> > You're getting this software for free rather than paying for something > expensive.

So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because _that_ is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained.

If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked.

This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?

<comment><USER11> > This "it's free so you get what you paid for, and if it's shit don't > complain because it was free" really rubs me the wrong way. It's a very > capitalist mindset that measures everything in money.

I mean like... yeah.

If I'm maintaining an open source project as a side gig or for fun, I might be able to review and merge some patches. But if the corporations that use my project submit a busload of PRs (or worse, just issues with no solutions) and I end up spending so much time on them that I have no time to work on my dayjob and make rent... that's not gonna work.

Now if those corporations each chuck a hundred bucks a month (less than the cost of a single Developer's Enterprise MSDN subscription) my way, then sure! I'll scale back my freelance web dev work and spend half my workweek dedicated to maintaining this project!

So yeah, I think the corporations who make money off open source projects should be kicking back a bit of money to those projects if they want an expectation of reliability. It doesn't have to be a ton of money either:

\- If we're talking about a tiny header parsing library that needs occasional security patches, maybe expense a few bucks at the maintainer's Patreon so they can spend 10 hours a year on those patches.

\- If we're talking about the web framework that underlies your big newspaper's CMS, maybe have a developer spend 20 hours a month pushing well made PRs to fix the problems you care about.

\- If we're talking about an OS like Debian and you're AWS, maybe hire a 3 person team to work solely on keeping it secure.

<comment><USER10> What rubs me the wrong way is the notion that if it's for free it has no worth. This "free == shit" idea that is expressed in "you can use it but don't expect much of it because it's free". Maybe I'm just too much of an old school open source idealist.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> This seems to be a case of mismatched expectations.

Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.

So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast _and safe,_ right?

But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.

Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.

I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially _unnecessary_ unsafe code. Actix-web was taking a lot of risk, more than people expected.

<comment><USER13> I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I reas the article I sensed your explanation was probably the case. Did the many safety-making patches cause the performance to go down?

<comment><USER14> Not so much mutually exclusive as "safe, fast, easy, pick two", at least sometimes. It can take a lot of design effort to come up with a safe _and_ efficient way to do some things, so it's often tempting to do something unsafe and efficient and hope it works out.

</comment></comment></comment><comment><USER15> I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees _ANY_ notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even _that_ large and I've seen lots of in fighting to the point where I've had to lock threads. The skills required for you to run a successful open spruce project are the same skills required for you to run a business. You're going to need people skills and understand how to de-escalate situations because once the community is large enough, there will be a lot of culture conflicts. The main challenge with open source is that if you're not getting actively incentivized (Paid for me) to maintain something that's super popular, it's easy to abandon it when things get hard.

<comment><USER16> It must depend on the project in ways I don't understand. Certainly while working on Firefox I saw tons of toxic behavior from users, and sometimes potential contributors. I've seen it in lots of other projects that I haven't worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish I could explain the difference, but I can't.

<comment><USER17> rr is only useful to people with a minimal level of knowledge, and in most cases to people who have stood in your shoes. Firefox is useful to any six- year-old with a cellphone. Maybe that explains the difference.

<comment><USER16> That could explain the difference between rr and Firefox, but it doesn't explain the difference between rr and all the other developer-oriented projects with toxicity issues.

<comment><USER18> There's variance in developer experience and skill as well. The software's purpose functions as an audience filter. There are still probably toxic people out there using your software, but not as many so they're less likely to bother you.

From what I've read about rr, it sounds like awesome black magic, and I'd imagine most users appreciate how difficult its task is.

</comment></comment></comment></comment></comment><comment><USER19> While I much appreciate Steve's work on Rust, this does seem a little high on drama and low on substance. Rust really does seem to be a nice language and here for the long haul so bumps in the road are opportunities for improvement rather than moments to sow seeds of doubt. From the link _title_ , I thought that someone had _died_ or that Rust was fundamentally broken, but:

\- The internet will be the internet and that's, unfortunately, here to stay.

\- Being a maintainer can be a _less than_ thankless job and that's a bummer but also a fact.

\- Reddit can be toxic, news at 11.

I had assumed that 'unsafe' was a rarely used aspect of the language (as it is in Haskell and as duck-punching is in Python). It seems necessary (to me). It _might_ be used more often than it should be? Hmm. Okay a little unsafe- coverage tool should allow for quick assessment. Of course, FFI libraries will be heavy on unsafe but use them at your own risk...

All successful software projects pass through previously-small-problem- becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal to JIRA..."). I don't find Steve's melodramatic response to an opportunity to "level-up" to be particularly helpful.

I do think it'd be great to have an unsafeness analyzer (if there isn't one already) and to expose those values in cargo.rs. And to follow other safeness- flag recommendations in this discussion. Were those in-place or in-flight, most of TFA would have been "the internet has driven away the maintainer of a good project and that's not good".

</comment><comment><USER20> Perhaps we can get at a deeper, more durable insight if we assume for a moment that most individual actors are well-intentioned, and that the described vitriol on one side and perceived stubbornness on the other is an externality of the unfortunate incentives (or lack thereof) that are parasitic on the open source community.

It's almost instinctual/natural to misjudge the popularity of any project for some false sense of security or acceptance. Just think about the numerous issues that plagued the Node community around NPM packages with large amounts of downloads and GitHub stars that turned out to be problematic.

For me the deeper insight here is that we all sort of want our cake and eat it too. Project maintainers/owners want the freedom and enjoyment of working in open source building fun and useful things without any explicit commitments, and that's fair and understandable especially without any formal compensation. And the users want to be able to have access to a growing collection of projects without having much skin in the game, i.e. paying for it.

This isn't a problem with people, this is a problem innate to open source, and the double-edged sword that it is.

<comment><USER21> It is a problem with people, people wanting to have their cake and eat it too. Open source is made of people.

<comment><USER20> You're right in the sense that, at the end of the day, almost every organizational/social structure is made of people. The interesting thing for me is to see what incentive structures are at play that incentivize otherwise good people to do apparently bad things.

We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.

</comment></comment></comment><comment><USER22> I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people have come to rely on.

Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.

It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.

<comment><USER23> The problem is that people didn't choose Actix only for performance. I personally haven't used Actix, but it seems that all other contenders were lacking in some way, not only performance but also feature sets and flexibility and easiness. And thus we are now left with a horde of safe but otherwise lacking libraries instead of what could possibly be the best of breeds.

<comment><USER22> That's entirely fair - and I wasn't saying that choosing actix was a bad choice at the time for the users - but I also think that the people who were willing to contribute to Actix to make it safer are probably also the type of people who are willing to contribute to those other libraries to make them more useful.

If there is one trend that has been consistent in the development world it has been that there are always people willing to keep iterating on libraries to get better and better implementations.

</comment></comment></comment><comment><USER24> I love Rust and use it daily.

Unsafe isn't something you live without, you just avoid unless there's a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You're not replacing decades of computing overnight, though, and it's not the end of the world if it's there sometimes.

It often feels like newcomers and zealots preaching the unsafe issue, too. I have to wonder if the Rust docs couldn't better point out "the goal is less unsafes, but unsafes will exist - this is fine". I know it kind of explains this already, but perhaps being more blunt?

Actix-web even with a few unsafe is still more sound than most frameworks IMO. I'll take slightly better with crazy good performance over not better at all with no guarantees.

Also, look, the other problem is Reddit: I'm starting to think larger projects should squat their name there and redirect to better discussion places. I comment on Reddit sometimes and I roll my eyes every time I've done it lately.

End rant, I guess.

<comment><USER25> You can't squat and redirect subreddits to external sites. I have personally been granted mod of a subreddit that had been redirecting to another website. Its against the rules and the subreddit will be banned at which point anyone can use /r/redditrequest to take it over.

Even if that did work however, people would create adjacent subreddits that would end up to be defacto sureddit, for example /r/competitiveoverwatch.

<comment><USER24> I'll defer to you on this, but I definitely know I've come across subs where this has been happening for years and they're not shut down.

<comment><USER25> Its completely possible that nobody has reported those subreddits to the admins.

</comment></comment></comment></comment><comment><USER26> > there's this style of response

This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of _fame_. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, _please_ watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. _Please_ watch the video!

The core problem is that fame used to be _opt-in_. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.

On the internet fame became something that _happens to you_ , because the internet _IS_ media access. We're used to seeing fame as something that was _chosen_ ; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means _walking away from your normal life_.

[1] [https://www.youtube.com/watch?v=PmTUW- owa2w](https://www.youtube.com/watch?v=PmTUW-owa2w)

</comment><comment><USER27> A few years back I started using Rust after spending many years working with Go full-time and the first thing I noticed was that the team really focused on only providing the language, that libraries like HTTP were being pushed out to the community to contribute. It's a totally fair position for a language to take, but I found it disappointing coming from Go where I knew I could just use 'net/http' and move on to solving problems.

This is the first I've heard of this conflict in the Rust community, but honestly it's not at all surprising. People write lots of web servers and if you're relying on your community to provide critical libraries (http is pretty critical in 2020) things like this are bound to happen. I really wish Rust core could provide a standard library of tools more akin to Go as I really enjoyed working with it when I was learning it.

<comment><USER28> The language team has been focusing on providing the primitives needed for an efficient HTTP client and server, that is, async/await. That only got stabilized a few weeks ago. If we had put HTTP in the standard library before then, it would have only been synchronous. That would have been a huge drawback.

<comment><USER27> Oh absolutely, you actually mentioned that to me a few years back when I was first looking at Rust, and that's a totally reasonable place to have been in. It's just unfortunate that so many people decided to depend on an external library/framework and then got upset like this. For me it meant Rust wasn't a language I should use for web servers at that moment, which hopefully won't be the case for too much longer. I will say that as a user it'd be great to see an officially maintained lib like 'net/http', even if it isn't a part of the std lib itself.

</comment></comment></comment><comment><USER29> This is very difficult. I feel badly for the author of actix-web, and I agree with Klabnik to the extent that Reddit can be a terrible place.

What I think this is, is a sad day for the Rust community.

But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily _good_ ¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.

But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.

Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.

¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being _benevolent_ , and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.

<comment><USER30> Not the point of this thread, but cabal is quite good now with its Nix-style local builds. The meme of "cabal is bad" perpetuated during the rise of stack is just wrong now :)

</comment></comment><comment><USER31> Question: why didn't the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

<comment><USER28> Forking is _extremely_ aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

<comment><USER32> > 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.

<comment><USER28> I actually agree with you in a general sense, but our own opinions don't really matter much. What matters is the opinions in the aggregate.

I _wish_ that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.

<comment><USER33> Why? What's the danger here? Is the original maintainer going to send someone named Vinny to break your legs if you fork a project that won't accept a security patch you need?

I think you should just fork it privately, apply your patch, and move on with your life.

<comment><USER28> If you're keeping it private, none of this applies. I'm talking about "hey that project is bad, I am now maintaining a competing project, please use it instead."

<comment><USER34> Instead of framing it as "that project is objectively bad, my one is better", why not say "my project is a fork of this project but with a bit less _unsafe_ " and then see what the community does?

Forking isn't provocative. Forking and then claiming your fork is objectively superior is.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> The larger pity, to me, seems to be the maintainer's decision to not only quit the project, but to take down the repo with the intent to delete it:

[https://github.com/actix/actix-web](https://github.com/actix/actix-web)

I get it, they feel personally harassed and slighted. And it's their project, they can do with it what they like. But it still feels like the decision is motivated more by spite than by a desire to simply wash one's hand of the project. Surely there are _not hostile_ developers who would've been willing to take over the maintainer role.

<comment><USER28> It got moved to their personal github account, not deleted.

<comment><USER36> He said he is going to move it to private in his [post mortem]([https://github.com/actix/actix-web](https://github.com/actix/actix- web))

<comment><USER37> This seems to me the most relevant quote:

"(Btw thanks to everyone who provided prs and other help!)"

So the maintainer was grateful for the PRs, but worn down by all the people complaining without contributing.

</comment></comment></comment></comment><comment><USER38> Here's the reddit thread in question:

[https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...](https://www.reddit.com/r/rust/comments/epoloy/ive_smoketested_rust_http_clients_heres_what_i/)

I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...

<comment><USER39> Yeah, I agree. "It's all reddit's fault" is not helpful at all and simply wrong from reading that thread.

<comment><USER28> You cannot get the full context from a single reddit thread; as I mentioned in the post, this situation is the product of multiple events. You'd at least need the posts from all of them, let alone that this is only one of the posts from this situation on reddit in the last day.

<comment><USER37> I think that's where some of the confusion comes in.

You say:

"Some people go far, far, far over the line."

So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?

<comment><USER28> Yes, they did. I posted an example of a particularly egregious one elsewhere in this thread.

<comment><USER37> Yeah, saw that. Criticism of code should turning into personal attacks is never justified.

</comment></comment></comment></comment></comment></comment><comment><USER40> This is an unfortunate, but I think necessary part of community growth. I really don't think it's possible to create a large community around a language that is business critical, and not have these kinds of setbacks where people get worked up and hurt each other's feelings.

Python has many of the same issues, where core devs and key maintainers go dark or behave badly. What Python does do pretty well, and what I like about it, is placing its core user front and center. For Python, that is the beginning programmer, and Python has a lot of empathy for him or her. What I also like about Python is a general willingness to have difficult conversations and back rebuttals with code snippets.

I read difficult conversations by Bruce Patton a while back, and it wasn't an easy read for me because I have problems of responding sometimes in a constructive manner, but I learned a lot and I would highly recommend it .

I'm confident the Rust community will survive this and come out stronger than ever :)

<comment><USER41> Yes, but I wonder how many of those 50K users are "business critical" and how many are there just for trolling, gossip and drama.

</comment></comment><comment><USER42> This is a sad day for Rust. Situations can spiral out of control. Who started it? Who escalated it? You can't really define these because communication is sloppy and difficult, especially when there are cultural and language barriers involved. The only way to not get these situations to spiral out of control are a thick skin, forgiveness, and assuming noble intent.

There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.

I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.

Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).

<comment><USER43> No, it's a happy day. This won't be the last such event. People who care will learn to keep track of details they care about, and certify -- and de-certify -- without drama. Not all modules are right for use everywhere, but all are right for use somewhere, including those only trusted for personal projects.

Some of the latter will be forked, and the forks certified to higher levels, and those forked again and the forks certified or de-certified again.

This marks a step on the way to maturity, right on schedule. By the evidence, in ten years Rust will be a mature language, much more quickly than some. Most don't get there.

</comment></comment><comment><USER44> I really want to like Rust. Every time I try to use Rust on a project, I end up down a rabbit hole of internet arguments and unnecessary drama. When I finally give up on Rust, I find I can accomplish the same task in a fraction of the time with a more mature language. At this point, I think Rust is best reserved for very narrow use cases that can be shown to fit neatly within Rust's current ecosystem before coding begins.

Rust is a macrocosm of a phenomenon I've noticed in my own career: My productivity is inversely proportional to how dogmatically "correct" I'm trying to be with my implementation. The Rust community embodies many of the negative aspects of perfectionism that tend to stall real world progress. That perfectionism doesn't necessarily carry over to your code, but I find myself wondering if I'm doing things "the right way" far more in Rust than other languages.

Some growing pains are normal for any community. I really hope the Rust community can settle into a healthy environment. Until then, I'll reserve Rust for only smaller projects where I can afford to bail and rewrite in another language if it starts to spiral in complexity.

</comment><comment><USER45> I love Neil Gaiman's "Entitlement Issues".

To sum it up: "George R.R. Martin is not your bitch."

I would carry this even further: "Open source maintainers are not your bitch."

I see a lot of whining and entitlement from engineers on open source repo issues pages. Open a pull request, fork it and host it yourself, and just relax in general.

Not to say maintainers can't be jerks. But again: That is their choice. They are not your bitch.

</comment><comment><USER46> Tried reading through this but without context it's very unclear what has happened.

Can someone familiar with Rust and it's communities explain from a high level what all this is about?

<comment><USER47> The really short answer seems to be: actix was a Rust web framework. It did some things internally that some people didn't like. The Internet echo chamber picked that up and amplified it to a volume the maintainer couldn't justify working through. The Internet echo chamber is now going to pick this up and amplify it to a volume that probably isn't justified either.

I think this is another story about the destructive power of the internet echo chamber, where the asymmetry of one person vs. a mob of people who are in reality probably not _all_ that engaged with the problem but nevertheless have enough engagement to send a nastygram or two creates a distributed denial of decorum attack that no single human being should be expected to deal with "nicely". Our ancient instinctive tribal signals of whether or not you are approved by the tribe, tuned for tribes of 150 people or so, receive a message that 15,000% of the tribe thinks you are a bad person, and our natural human response to that is a lot of stress at best (our ancient instincts tell us that eviction from the tribe is a _bad thing_ , even though in practical terms eviction from this particular tribe won't be much of a problem at all in the modern world).

(I phrase it this way because I think this is, well, not strictly speaking _independent_ of the question of whether or not the maintainer was guilty or innocent of any particular thing, but because the story is the wild disproportionality of the response you can get on the Internet regardless.)

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

</comment></comment></comment><comment><USER49> A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this.

I have two simple mantras which establish my philosophy here:

1\. YOU are responsible for your dependencies.

2\. Open source participants are volunteers and owe you nothing.

It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest. Your dependencies are your responsibility. Responding with vitrol, anger, or hate when failing to uphold this responsibility bites you in the ass is just being a jerk.

User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. I don't stand for it. If any other maintainers out there are struggling with this, please send me an email: firstname.lastname@example.com. I'm sympathetic to your cause and I can likely lend some pertinent advice.

<comment><USER5> > 1\. YOU are responsible for your dependencies.

They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back.

Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code.

Sadly, that led to some comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.

<comment><USER50> > Having a project maintainer then call those patches boring or otherwise > disregard them? That's childish

So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one.

With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using.

This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.

<comment><USER51> It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.

<comment><USER52> Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

<comment><USER53> Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context.

Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."

<comment><USER54> They actually do exactly that. The only goal of Ubuntu is to provide usability. They will care about security to an extent it does not interfere with that goal.

Such as maintainers being overloaded fixing visible issues.

You want a security oriented distribution, you picked the wrong one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER55> I remember when people were claiming Common Lisp community is toxic, but I find that it is the languages which tend to focus on "building community" with Community Managers and Codes of Conduct that end up becoming truly toxic cesspools in the end. See also node.js. The focus on community attracts people who aren't interested in programming, but rather those who want a playground for gaining clout and trolling. You never hear about C++ drama, why is that?

<comment><USER56> Primates tend to attack each other out of envy when they become too similar and all behave the same exact way. They look to find someone to crucify to get rid of the angst built up from being too similar to the next person.

The Common Lisp community was pretty much the opposite of the Node/Rust crowd. Everyone was different. Lots of people were using different implementations of CL. Most people even had their own custom editors. And of course everyone had their own DSL of macros they carried around with them, so basically everyone had their own language. The supposed toxicity of the CL community was from the constant arguments because they all had strong opinions different from each other.

If this were the CL community, there would be 20 different versions of actix- web or something like it. There would be no need to create drama and make whiny demands of other people, because everyone in CL actually knows how to program.

</comment></comment><comment><USER57> I don't think a few compiler engineers can hold themselves responsible for the Twitter/Reddit behavior of thousands of programmers (which at this point are selected more or less evenly from the whole population of programmers), no matter how noble the sentiment might be.

</comment><comment><USER58> What makes me sad is that someone spent a huge amount of time making something, working on something, supporting something. If you don't like that something, then use something else or write your own thing. I don't get how there is some responsibility of maintainers to turn a passion project into anything other than what they want?! Fork.

</comment><comment><USER59> I think there are three things that combine to cause the underlying problem:

1\. Open source creators own the package and they owe you nothing. Most (all?) of the major package repositories follow this model.

2\. There are very few ways to officially fix a major dependency if the creator(s) take a powder beyond cajoling or forking and attempting to maintain it yourself.

3\. Many people are using VERY complex and important packages that, frankly, they may not actually be able to maintain themselves. I fall into this category for some packages that I use and I'm sure most people do, especially on small projects.

So, you are left with hoping the OS creator stays on top of things or cajoling.

Once cajoling fails, and you are in a bind, a bind that may threaten your job and career; things get ugly. It's not right, but it's human nature and it's predictable.

I'm identifying the problem, I really don't have a solution.

</comment><comment><USER60> There are a few project management techniques that can avoid a lot of this. Mainly, don't submit a PR until you get a maintainer's approval on the purpose of the issue and the plan for the implementation. Time is valuable. When I want to convince maintainers to spend their time on my issues, I try to pitch in a way that requires the minimal time investment from them. Ask yes or no questions, provide multiple proposals with pros/cons, and look a past PRs that have landed so you can replicate the qualities of an acceptable PR. A few of these lessons were learned from successful OS projects with issue templates that gently guide contributors. Most of them were learned the hard way by misguided effort wasting a lot of peoples' time.

</comment><comment><USER61> Steve, you have done a fantastic job. Don't let these issues get you down.

As an indication of that, I've been implementing an ownership/borrowing system for D. I expect to see some of the same issues you brought up. But for the people that want to use it correctly, it will produce the benefits. And that's what I care about.

<comment><USER28> Thanks Walter. I've been following along with your work, actually, though I don't know enough D these days to really understand it fully. Neat to see though!

<comment><USER61> I don't fully understand Rust, either, so we're even!

Don't worry about the haters. If I paid attention to them I never would have accomplished anything. People are always going to misuse a tool.

And some good news, the first stage of D's Ownership/Borrowing system was pulled today!

[https://github.com/dlang/dmd/pull/10586](https://github.com/dlang/dmd/pull/10586)

</comment></comment></comment><comment><USER62> I used to have this mental model for my (few, meager) open source projects: "I'm making something really cool in my back yard. You can come help when I'm home."

Eventually it's mutated into, "I'm making something really cool in the local park. I'll be there on weekends!"

I had to bake in the perception of not "owning" my creation because yeah, at some point it needs to grow well beyond what I had the time/energy/capability for. I'm also very human, and very insecure about my competencies, and as the youngest of three brothers, am defensive by nature.

Now practically speaking, how do you accomplish that in the open source community? I wish I knew.

</comment><comment><USER63> I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in the Rust community. Now it's come back to bite them.

Language design that forces users to lie to the language leads to this. The classic is C's "a pointer is also an array" mindset. When you write

       int read(int fd, char* buf, size_t buflen)

that "char *" is a lie. You're not sending a pointer to a single character. You're sending a reference to an array of unknown size. That design mistake in C has probably been the cause of more serious bugs than any other mistake in the history of programming. If you have to lie to the language, the language is broken.

Rust had so much promise, too.

<comment><USER64>
        there are things that you either
        can't express, or are very hard
        to express, in safe Rust.

This is true (and in some sense inevitable by Rice's theorem) but it is unclear what can be done about this. Bear in mind that Rust's design constraints are

\- decidable (indeed fast) type-inference/type-checking

\- simple typing system

\- you don't pay for features you don't use

It is easy to get rid of unsafe blocks if you throw complexity at Rust, e.g. use dependent types and / or theorem provers, but all the obvious ways of doing this immediately violate the constraints above. Doing it within Rust's constraints is an open research problem.

       potentially fixable.

What would you use as an objective, measurable criterion that we can use to decided whether a purposed fix is in fact a fix? If you have a concrete design proposal that works (in particular w/o destroying Rust's fast (bidirectional) type-inference/type-checking and the simplicity of Rust's types), and evidence that it's widely applicable (i.e. doesn't just allow to type some trivial edge cases of back-links and partially initialised arrays) that would easily publishable in top PL conferences (e.g. POPL) and a working prototype would help towards getting this into Rust.

I would be happy to help with implementing & writing up such work. I have quite a bit of experience with sub-structural types a la Rust. I have spend some time thinking about this problem space, but didn't manage to crack it. I have an incoming PhD student whom I could ask to help with this.

<comment><USER63> Oh, not Rice's theorem again. That only applies to infinite systems. There are useful decidable properties for a reasonably large set of programs. Yes, they're "uninteresting" mathematically, but we're talking about memory safety here. If your program is anywhere near undecidable in that area, you're doing it wrong. Any time you're close to the edge on that, you can get decidability with a run-time check. The Microsoft Static Verifier people have been down that road with some success. I went there 40 years ago, with the Pascal-F Verifier.

The question I'm asking is, what do you _really_ need to do that you can't do in safe code. On the memory safety front, for pure Rust (no calls to C), probably not all that much. Maybe only this:

\- Syntax for talking about partially initialized arrays. For a collection, you have a variable that indicates how much of the array has been initialized, and you need a statement in the language that ties that variable to a partially initialized array. Then you can do simple inductive proofs to show that as you initialize another element and add 1 to the counter, the entire array is initialized. Non-consecutive initialization would require more complex proofs. Is there a real use case for that? One with major performance implications, where initializing the data to some null value would be too slow?

Un-initialized blocks of types such as raw bytes aren't a problem, because those types are "fully mapped" \- all bit combinations are valid. Only types that are not fully mapped an initialization guarantee.

\- Backlinks. Backlinks in doubly-linked lists and trees obey some simple invariants. You need syntax to say "this is a backlink". That implies an invariant that if A points to B, B must point back to A. Everything which updates A or B must preserve that invariant. The pointer from B back to A then no longer needs to have ownership of A. (It's a problem that Rust doesn't have "objects", because such invariants are usually required to be true when control is outside the object, but can be broken momentarily while control is inside it. The inside/outside distinction is important for this, and Rust is a bit soft on that. Spec# took inside/outside seriously, but viewed it dynamically, rather than being tied to static scope. Haven't looked at that in years.

What else do you _really_ need? Remember that some knotty ownership problems can be resolved by allocating the objects in an array which owns them, and using array indices for relationships between the objects. It's not like you have to use pointers.

Concurrency is a related issue, but I've said enough for one night.

<comment><USER64> I'm still unclear about this, should this be done by the typing system or by an external static verifier:

       simple inductive proofs to show
       that as you initialize
       another element and add 1 to
       the counter

If the latter, you can already do this with Rust as it is, it's just a question of building such a static verifier. If the former, I really doubt that this can fit in Rust's typing system without major surgery. We know well how to add arithmetic to typing systems, but the natural approach to doing so (dependent types) will probably make type-checking / -inference undecidable.

</comment></comment></comment></comment><comment><USER65> I think one part of this problem is that people need to mind their own business. If you're using an open source project and you find a bug then fine, report it. Hell, maybe even do a PR for a fix. But the you're not the maintainer's boss, they don't owe you a fix, they don't owe you anything. Now here's where it goes wrong, it's not your business to go and call someone out on social media. Not least because when you post on social media you should know that you're inviting a lot of strangers who have nothing to do with your problem to come and get angry. A decade ago maybe you could've feigned ignorance. Not today.

Equally, if you see someone complaining on social media about something that doesn't effect you, then mind your own business. But let's be clear - <USER2> people can't be trusted to do that.

Social media has taught everyone that they get to have an opinion about everything, and not just to have an opinion but to go and find the people involved and tell them. That is a completely broken culture- and its actively encouraged by places like reddit and twitter.

</comment><comment><USER66> It brings up the question — as a developer, how can you best set boundaries on your customers so that you can have some degree of control over the toxicity of the culture that you're exposed to when interacting with them?

<comment><USER67> It's a good question. I'm involved in a large open source project that attracts some of this kind of attention. Because of the project's age, much of our infrastructure is old, which actually sort-of works to our advantage here. If you want to be a jerk to us, you need to go find our mailing lists and figure out how to send an email, or register a Bugzilla account and go file some troll bug. Much more effort than posting "You Suck" on GitHub or whatever. The barriers are insulating, which has pros and cons.

The other part that works well for me is disassociating your self from your project. Set strict hours for when you will work on the project, and don't work on it outside of them. Note that checking issue emails counts as work; remove your "work" email from your phone. I'm lucky enough to be a paid developer for the project, so I can clearly define my working hours as when I'm in the office, and ignore issues when I'm not at the office. But even for personal projects, there's no need to respond to issues within hours, or even days, if doing so is burning you out.

And the obvious answer that applies to anyone who creates anything online: Don't Read The Comments. In this case, that means Reddit. Reddit is a cesspool of uninformed users giving maximum visibility to whatever is most appealing to other uninformed users; not a good place to get useful feedback. Find spaces that are supportive and provide useful feedback, cultivate them, and spend your time there.

<comment><USER68> Hm, dunno, I am tangentially involved in a big open source project which almost never gets any negative comments, neither on Reddit nor here and the feedback is usually useful. Yes, the project uses mailing lists for the development, but there is almost no negativity in other parts of the community.

I have no idea why some projects gets toxic attackers while others are almost entirely spared. One thing which the project prioritizes is taking the time to explain to people why their ideas which look good on paper may actually be missguided.

</comment></comment></comment><comment> nevi-me 1\. fafhrd91 might not be an English "native". A simple linguistic look at his comments (esp on gitter when he answers our questions) shows that he uses very short sentences. Perhaps that comes across as harsh to some people, but for the most I think it was fine. Perhaps many of those who were offended took this the wrong way (one can't keep apologising for their English).

2\. Perhaps actix focused more on TechEmpower benchmarks (if you follow fafhrd91 on GH, you'd see the number of times he forks TE's repo, presumably submitting PRs). I think having a library that's #1 for many benchmarks attracts users, not all of which will be hobbyists working on toy projects. The concerns (some valid, most not) about unsafe were bound to be there.

3\. The dismissal of `unsafe` alternatives was often a challenge (from the comments that I saw, especially before his first instance of walking away), which wasn't handled well by "us" the religious cult. I don't know why he came back after the first instance last year, but what many of us saw was the toxicity of Reddit when it came to actix. I think fafhrd91 asked for people to co-maintain last time, which did see an increase in contributors.

4\. Part of us building a community will be many of us acknowledging that "Performance" is not the sole goal of every Rust project. There are sometimes people who will suggest a huge deviation in a project because of some micro- optimisation or because they want a feature which might not make sense for everyone else. So I hear what you're saying about the hardships of maintainership because things can go pretty wild if one tries to please everybody. Unsafe is also still 'young' in that more tooling around it will still be worked on over the years/decades. How will we know if we're being restrictive on a feature if we forbid it?

5\. Reddit is toxic. People on Reddit are toxic. People are toxic. We are toxic.

A good principle for us to follow when we type things on the internet is to ask "would I say everything this way to a person if I was standing next to him/her/them"?

Good luck Nikolay, I wish you the best, we have learnt a lot from you on what's possible in our little community.

</comment><comment><USER69> Rust is unique in that it attracts:

\- Language theory enthusiasts, a famously pedantic group

\- Systems programmers, a famously exclusionary group

\- Unwashed masses of web developers who have never done either of the above before

Frankly I'm amazed it's been as civil as it has been

<comment><USER70> I wish I could upvote this many times.

</comment></comment><comment><USER71> One thing that isn't considered is that these "benchmarks" are a rat race to the bottom in code quality. You can't blame the author(s) from wanting to win this fictitious wall of fame. I don't know why exact numbers like "6.9987 million/sec" exist. There should be a saner way to run benchmarks, which in turn creates sanity among developers.

This viewpoint is, of course, unrelated to the community discussion here. I mean other languages have unsafe (or c's void *), but they don't appear to fight about it. I don't mean to say anything bad about Rust. But it seems to attract people who want the absolute best performance at any cost. IMHO. May be I am wrong. That may be something Rust people can try to change??

</comment><comment><USER72> I think the simple version is that too many people don't understand how Open- Source works and that they have no right to tell a maintainer what he has to do.

If you are unhappy with the direction an Open-Source project is going, you can do two things:

1\. Tell, in a civilized manner!

2\. Fork, if you are willing to spend the resources to maintain such a project yourself

If you are unable to formulate your critique in a neutral way, then keep it to yourself (aka STFU). If a maintainer decides he doesn't want to follow your suggestions, you should be nice and stop. After all, you still have option two.

And if you are unwilling to spend the resources to maintain a fork, how dare you to tell someone who invests his time and shares his results, what he has to do.

</comment><comment><USER43> A necessary step on the way to Maturity. On Schedule.

Congratulations, Rust!

I mean this with no trace of irony. With maturity comes being used in ways you didn't intend, and might not want, even with unwelcome publicity. Rust will sail through more of these, and more, and they will cease to shock. People who care will start to pay attention to modules' underpinnings, and start to keep track, and certify. It takes a lot of conscientious people caring to uphold that, but maturity brings them.

Rust is designed to a high standard, and it takes extra work and extra armor to maintain it, just as it is worth the extra effort to learn it. It aims to be worth that, so we cannot begrudge that without betraying its purpose.

</comment><comment><USER73> To start: any personal attacks against the author are unacceptable. Anyone is free to write whatever the code in Rust they like, and it is wrong to attack them about it.

But .... I think it is showing that the premise of memory safety in Rust is working. Stuff that would go unnoticed in C and C++, is being identified and called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe. But from the perspective of the potential Rust user it's a proof that it `unsafe` keyword works, leads to higher scrutiny of potentially dangerous patterns and that the culture of other Rust users takes reliability, security and safety seriously.

<comment><USER74> > Anyone is free to write whatever the code in Rust they like

Let's take an extreme example: I write some program for common use and intentionally introduce a security hole or make it participate in bot-nets. And don't tell anyone about it. Am I "free to write it because I like it"? Well, in some sense, maybe, but it would also be something extremely problematic for me to do. Certainly everyone would scream bloody murder when it gets found out.

So, in a less extreme example, there's still some measure of responsibility of mapping out what and how you've vetted, and not making false claims.

<comment><USER75> I think if you're actively deploying malware that people will run, the case is pretty clear. And when you say "for common use", it sound like you know that it is or intend it to be distributed and run by many people.

What's less clear is security holes (which are not malware as such) or just "putting code out there" ("not in common use", although someone could come and pick it up and start using it). I _would_ defend your right to write exploits and backdoors and bots and put them on github.

Simply making a security hole is IMHO OK unless you have intent to exploit it (or let someone who intends to exploit it know about it).

The difference, for me, is in writing versus deploying. And I'd consider it deploying if you intentionally post malware to a public repo you know people will run (without knowledge of having malware in it).

Contrast with building a trap (and maybe showing it to people) and stashing it in shed, versus building a trap and priming it and putting it in the woods where you know kids like to play. Not a watertight analogy, I guess making traps could be illegal just like making guns is in many countries. But you get the idea. I think you should be allowed to write malware or make combat knives or mantraps for fun but don't put them to their respective use.

Of course, going down this line of reasoning is a rabbit hole. If you build something on your yard (something that isn't illegal per se and has no intention to harm anyone) and it turns out to be dangerous and someone gets hurt, you might have to take responsibility (but it _really depends_ on a lot of factors and would be decided on a case by case basis). I'm not sure I would like such reasoning to be applied to FLOSS projects that come with a warranty disclaimer and which can freely be audited by anyone who intends to use them for real. It's not like they hurt you just because you happened to stumble upon them.

</comment></comment></comment><comment><USER76> What's all this BS drama? It's the original maintainers project, his way or the highway. Those who don't like his use of unsafe can take a hike, fork it, write their own etc.

If the project owner just wants to use Rust as a fancier C, just for a few niceties, and mostly code in unsafe, that's their decision to make.

</comment><comment><USER77> """ But the point is, while Reddit is not official, and so not linked to by any official resources, it's still a very large group of people, and so to suggest it's "not the Rust community" in some way is both true and very not true. """

Perhaps one could call it "the unsafe Rust community." ;)

<comment><USER78> The word "community" comes with some troublesome implications. Just call it "the unsafe space (and proud of it)"

</comment></comment><comment><USER36> I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it. People depend on this software. It is inconsiderate to just move it to private instead of taking the time to hand it off to someone else.

I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder what my client will think if I bring that one up? I hope there is a community fork with enough momentum to keep the project alive.

<comment><USER79> You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free.

Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk.

Expecting, demanding, or begging for anything except what the author willingly, and happily takes upon themselves is exploitation, pure and simple.

If you think about it, trying to coerce an author/maintainer into doing anything they willingly and explicitly have commited to, is no different than employing bullying, group pressure, and other social/psycholgical manipulation techniques to get whatever outcome others deem useful to themselves.

Yes, something as trivial as complaining about the lack of response to a question can easily be seen as being abusive when there is no established relationship or expectation, no quid pro quo, or similar.

Getting free access to someones work is amazing, and nobody should ever have to face what so many maintainers have to face today in the form of unreasonable expectations and outright bullying.

<comment><USER78> > You don't get to invoke professionalism, or lack thereof in regards to some > individuals work they've made available for free.

Plenty of people do exactly that: they point to work that they've made available for free on their GitHub as proof that they have the required skills and attitudes for professional work. The former Actix-web maintainer also used to do this, via their LinkedIn page. You can't have your cake and eat it too.

<comment><USER75> Linking a hobby project isn't necessarily meant to say anything about attitude at work. At work, the expected attitude might very well be that you have to bend over for and pamper customers and deal with no end of bullshit. Or maybe the expectation is that you never interact with customers directly, everything goes through customer support / sales / executives (after being checked by legal). A hobby project, by contrast, is your kingdom, and you can reject bullshit and/or have fun or just never respond to tickets without a patch because it's your free time and your pet project.

If I link my stuff or show it to a prospective employer, it's meant to show them that I can code. Nothing more. If they want to read too much into it and dismiss me as unprofessional because they found a cat meme, Theo quote, or link to hello.jpg, it's their loss not mine. Fuck 'em. Kinda unprofessional of them.

</comment></comment></comment></comment><comment><USER80> This all boils down to _entitlement_...

If you want a committee to answer for maintenance and philosophical debate or whatever, then fork and form an organisation for it... if not, leave people alone ffs, a one person authored project that got popular does not deserve this, abandonment is the only outcome.

</comment><comment><USER81> > "Why Reddit is like this" is a whole other essay; I think it's built into > reddit's structure itself.

Classic Eternal September.

Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new users mimicking other new users, and the culture shifting towards the platform's identity instead of retaining the sub's identity.

Generally, the type of person to post on Reddit frequently enough, has social cohesion problems that may preclude him from fulfilling his social needs through more healthy avenues, like real life. The same is true for the majority of people that post online frequently. Usually the pyschological profile that follows that point is one built on abrasiveness, distrust and aggression towards authority, an inability to adopt social manners and participate in social contract, low emotional intelligence, etc.

All of the aforementioned behaviors culminate into the toxicity and vitriol you usually see -- and as well why it's so prevalent.

<comment><USER82> It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself:

1) _[T]he Rust project saw Rust as more than just the language..._

2) _unsafe... is a really important part of Rust, but also a very dangerous one, hence the name._

If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that cause fervently.

And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.

People who perceive themselves to be defending a cause against danger are going to react very strongly, much more so than people who are criticizing an implementation choice on purely technical grounds.

<comment><USER83> > And introducing the language of "safe" and "unsafe" isn't just descriptive, > it's a value judgment. It has connotations of recklessness at least, and > explicit threat at worst.

Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necessarily a value judgment. In that context, "unsafe" just means "the compiler can't guarantee the behavior that it can normally guarantee".

<comment><USER28> You are correct.

That doesn't mean that people will incorrectly interpret it, though.

<comment><USER84> Ada's language is probably clearer and less loaded: checked and unchecked.

<comment><USER28> Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names.

The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)

<comment><USER83> I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.

<comment><USER28> Bike shedding is a structural description, not a value judgement. It's about technical complexity, and changing a keyword is one of the most minimally complex bits of language design.

<comment><USER83> My point isn't to argue over the definition of bike shedding. If the name of this keyword is contributing to this undesirable community outburst, then its name matters, and discussions about its name are important. That's all I'm saying. If that's what you originally meant, then we are on the same page :).

<comment><USER28> We are on the same page, yes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER85> Previously, in the Ruby community: [https://blog.steveklabnik.com/posts/2011-08-19-matz-is- nice-...](https://blog.steveklabnik.com/posts/2011-08-19-matz-is-nice-so-we- are-nice)

<comment><USER28> That situation is a little different for a number of reasons, but the broad strokes are the same.

Sam tweeted at me recently about this situation: [https://twitter.com/sstephenson/status/1167856878673694728](https://twitter.com/sstephenson/status/1167856878673694728)

</comment></comment><comment><USER86> I think this has less to do with Rust and more to do with people using the Web as a tool to be unkind to what they think are unhuman pixels.

Sometimes I think the Web was a mistake, and that none of us are ready for the scale that it brings.

</comment><comment><USER87> Fork. That's the answer. It's not friendly or nice or kind or whatever, but that's the answer. Rust and its ecosystem of people and their work are not magical; there are and will be difficult people and yes, sometimes the correct answer is to shun them by forking the work and leaving the problem children behind. It is impossible to avoid this when building a complete language paradigm involving so many people.

Nikokay isn't the problem. His indifference to soundness concerns is inevitable; Rust pragmatically doesn't preclude reckless programming and that's a good thing except that some people will, in fact, be reckless. The actual problem is the naive expectation that Nikokay's indifference and recklessness can somehow be fixed by the 'community.' It clearly can't. The 'community' needs to sack up and fork stuff until it's happy with the work.

</comment><comment><USER88> This is really bad. Actix Web is such an awesome framework.

Reddit has become such a toxic place since they optimized the platform to make money.

Why don't those idiots just fork Actix Web and make a "no unsafe" version of it? Instead of harassing the author, who has devoted so much of his time and talent to building this great piece of software?

</comment><comment><USER89> Open source frees us from the tyranny of the maintainer, but only if people stop raging at maintainers and start forking shit, and other people stop raging at maintainers and start voting with their feet to other forks.

Who the fuck cares if the package maintainer does or doesn't do x,y, or z.

Either make the patch, submit it, and launch your fork when it gets rejected, or look for such forks. Anything else is just masterbation.

On another note: it seems like this entire mess was based around a bunch of peoples inability to see that "can" != "does". The fact that it can be vulnerable because it doesn't do something that makes being vulnerable impossible does not in any way mean that it is in fact vulnerable.

This is like the time somebody came to our repo with a bunch of pep8 linter warnings and treated them like high severity issues.

"good practice" != "must do".

</comment><comment><USER90> I think Github (and other services that host OS software) needs something like "thank you box", that's just alongside Issues. Even if I am not able to contribute to some project I use and like (mostly because I don't have enough technical knowledge yet) very often I would like to - at least - say how much grateful I am for what this person is doing. There is some need for positive energy or gratitude, as we - who are happy - won't usually post an Issue saying that we are happy, everything is working fine. It seems then that there are only issues, and people who are angry or unhappy seem to be the loudest. How else, we who are grateful but silent users - can help maintainers and contributor to know that there is large or even larger amount of people who are happy and even amazed by their work?

<comment><USER91> GitHub has a donation feature, which is up to the maintainer to enable for their project. Otherwise, it seems to me that a stream of positive comments would get old quickly.

</comment></comment><comment><USER92> > It's unfortunate that a well-known project had soundness issues. It's > unfortunate that the maintainer wasn't receptive to fixing them. At the same > time, I've been there: being a maintainer is tough. It's also unfortunate > that there's this style of response, and kind, and volume. It is true that > the situation was dangerous. But did it have to be handled this way? You > have to understand a lot of nuance here to even know the main points of the > story. One version of this story that will certainly be told is "The Rust > community says they're nice but they will harass you if you use unsafe > wrong." Is that what we want? I, for one, do not. If you're a part of Rust, > you gotta ask yourself: are you happy with this outcome? How did your > actions (or lack thereof) contribute to it? Could you have done something > better?

</comment><comment><USER93> IMO, the most telling point of this is when the author rejected a security patch because it was not creative enough. He was more of an artist than an engineer.

 _What was the patch? It was very strait forward, simple, uncreative change, intention was just to remove unsafe not to fix existing code. I believe software development is one of the most creative work we do, and creativity is part of why we love software development, why it is fun. Especially if you combine it with real world projects constraints. "creative constrains" could be source of very interesting solutions. Being on the edge of your abilities is super fun. So uncreative change felt boring_ [https://github.com/actix/actix-web](https://github.com/actix/actix-web)

<comment><USER94> > He was more of an artist than an engineer.

Assuming this is true: What's the problem with that?

<comment><USER5> The project was not promoted as that for a long time. That "view" on what the project was only came yesterday, when yet another security hole was identified and a patch was prepared.

The impact of that patch would have likely caused actix to no longer be at the top of the techempower benchmarks.

</comment></comment></comment><comment><USER95> "I assumed that over time, the community would grow, and we'd encounter problems.

Today is the first day where I say to myself, okay, has that happened?"

I think it depends on how you define community. I used to think Rust was going to be able to go mainstream. Now I'm wondering if it isn't niche. In other words, infrastructure needs code too, but all of the code "at the edge" (ie. applications that interact with users) may not be the perfect place for Rust. And I feel like that's where the majority of code will be written. So, maybe to produce metrics on this I would start with "where is the primary activity", and discover within that niche whether or not Rust has positive trajectory in terms of "market share" of that category of applications.

</comment><comment><USER96> If your language promises some kind of new feature (e.g. "safety") but offers a back door you could drive a truck through (e.g. 'unsafe'), then ensuring that back door is used appropriately and in good taste comes down to _culture policing_ , which, as we've learned in other areas, is something the internet does not handle well.

As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, in general, it can't. But maybe Cargo could exercise some editorial control, and delist (or flag) packages that don't follow the "community standards". I'm not saying this would be a good idea, it's a tradeoff. But you can't force open source volunteers to write code in a way you like.

<comment><USER97> I would prefer to see a positive badge for "this project doesn't directly use unsafe" or similar, which maintainers can choose to put in their README in the same way that they currently put build-status, test-status and other badges. The actual badge state is produced by tooling (a CI system) so it stays up to date and you can follow a link to a (tooling generated) report with more info, so it's relatively easy to verify.

Maintainers that don't care don't have to use the badge (even if their project does in fact avoid unsafe), but the choice to include the badge acts as an implicit signal of intent. When I see a crate with green CI status badges (or in this case a green safety badge) that's a signal I can use to help judge whether I want to depend on the crate.

No one needs to be flagged or called out if they're not interested in that aspect of maintainership.

I think the hard part is that actual quality is a spectrum and no-unsafe-at- all isn't necessarily the best goal for many crates. So ideally the badge would show some more granular safety score. But scoring effectively is difficult, and the so is correctly interpreting a heuristic score.

<comment><USER97> Oh, and apparently there is something vaguely along these lines already:

[https://github.com/rust-secure-code/safety-dance/](https://github.com/rust- secure-code/safety-dance/)

</comment></comment></comment><comment><USER77> I haven't seen the phrase "contempt culture" before, and I want to thank Steve for bringing it to my attention in this article.

Thanks Steve. :)

<comment><USER28> You're welcome; I think it's one of the most important concepts for programming communities to understand. Felt like a revelation when I read it, as someone who was previously very contempt-ful and regrets it.

</comment></comment><comment><USER98> For me this says more about the drawback of easy and automatic dependency management. When I write C code, adding dependencies is often a huge pain in the ass. You need to figure out how it's packaged, how it's build. Should I build a custom version or just use $distro's pre-packaged version? How do I tell my Makefile/configure/CMakeLists where to find the headers and libraries?

This is generally a bad thing. It leads to NIH, to poor portability, to difficult integration in other dev environments etc... But it does mean that you carefully consider every dependency that you must use. The quality of the packaging is often an indication of the quality of the code too, a well polished build system inspires confidence, a crappy buggy bespoke shell script less so.

Meanwhile take this example: I've re-started working on a PlayStation emulator a few weeks ago. I haven't reached the point where I need to display images or output sound, it's pure algorithmic code with no I/O so far. That's 0 dependencies.

But then I wanted to add some basic logging infrastructure to be able to do 'warn!("this thing shouldn't happen")' or 'debug!("this register has value {:x}", val")'. I could just use println! but, hey, adding dependencies is super easy and I'll end up with more flexible and expressive code, so let's do that instead. So I add these two lines to my Cargo.toml (note the _simple_ in simple_logger):

        [dependencies]
        log = "0.4"
        simple_logger = "1.3.0"

And as easy as that I have a proper logging framework available. Amazing. Except that when I then run `cargo build` I see the following:

        Compiling autocfg v0.1.7
        Compiling libc v0.2.66
        Compiling log v0.4.8
        Compiling lazy_static v1.4.0
        Compiling cfg-if v0.1.10
        Compiling num-traits v0.2.10
        Compiling num-integer v0.1.41
        Compiling atty v0.2.13
        Compiling time v0.1.42
        Compiling colored v1.9.0
        Compiling chrono v0.4.10
        Compiling simple_logger v1.3.0

That's 12 dependencies for a glorified println! implementation. Did I vet this code? Of course not. It would be faster to just reimplement it myself. Do I trust that somebody went to the trouble of doing it for me? Not really. I just cross my fingers and hope for the best. It's wonderfully convenient but I'd be very wary of trusting any security-critical project with a dependency graph like that, and it's quite paradoxical since Rust is all about safety.

Oh and beyond that Reddit is a terrible place that manages to be the worst of 4chan and the worst of Facebook in one convenient package and should be avoided at all costs, but we already knew that.

</comment><comment><USER99> What I see: unsafe should be used sparingly, and it turns out there is a crowd-sourced safe-guard to ensure it. Don't cross the threshold.

Be warned: unsafe causes both bugs and anxiety - excessive use will lead to at least one biting you.

</comment><comment><USER100> Help me out here is actix-web some sort of software that is integral to Rust?

If not ... I get the idea he wasn't really welcoming of the changes but at the same time. It's his code man.

I came from the world of networking and etc and the world of programming has a great deal of personal preferences / hypothetical problems / "we don't do that at my workplace" stuff pushed under the guise of technically correct ... sort of technical bullying.

Under that sometimes there's little room for mistakes / other points of view, other working styles, and etc... and it's really horrible.

<comment><USER28> Integral? No. Used in production, by companies? Yes. Outwardly visible? Absolutely, due to Techempower.

Rust will survive without actix, but losing it is a setback for Rust in the web space.

<comment><USER101> If it's LGPL can't someone just put up a new fork of it and people transition to that?

<comment><USER28> It is MIT/Apache2, and yes, in theory they can.

</comment></comment></comment></comment><comment><USER102> Elm packages are not allowed to use JavaScript, period. I personally thought this very restrictive and unnecessary. But after seeing this, maybe Elm/Evan is doing it right after all.

</comment><comment><USER103> 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.

</comment><comment><USER104> I generally believe people should be polite.

But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty.

We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and then that project has unnecessary and flawed use of something that undermines the messaging around rust. This is a risk for Rust - a promising and popular project in a popular space that undermines some of the core rust messaging is a PR problem for the language. The maintainer not being receptive to contributions to resolve this difference is a problem. The maintainer not being receptive to contributions that fix SECURITY ISSUES is a MAJOR problem.

Open source maintainers are, of course, volunteers. I don't think we should hold them responsible for the fact that there are bugs in their code, or even security flaws. People aren't perfect, and no one should be expected to be, especially when contributing something to the open source community. But we SHOULD hold them responsible for not fixing security issues. It's irresponsible to release something to the public that you know puts them at risk.

So is it fair for people to be upset in this situation? I think so. I also think their reaction should be a polite one - but it's totally fair for people to push someone to take responsibility for code they've introduced to the world that has security vulnerabilities in it.

<comment><USER105> Exactly! Everyone should demand a full cash refund for all that they paid for the maintenance of that piece of software.

<comment><USER104> This is a common snarky retort when any discussion happens with open source software, but it doesn't add anything to the discussion.

There is a cost to using software that goes beyond money exchanging hands. The maintainer has no legal obligation to do anything, but acting as if someone having an issue with software having security vulnerabilities is someone being entitled is a childish reduction of the interactions in play here, especially when people are taking the time to write code that resolves the issue.

<comment><USER105> Why do you think it adds no value?

It at least makes it very clear to those who have not paid for the maintenance that their position is silly if they make demands of the maintainer. It is his project and he does as he pleases. Why is that difficult to see?

One could perhaps persuade him to accept a patch but like any endeavour where you need something from another person, either you offer them something in exchange (which they value enough) or ask nicely and see how it goes.

In either case, it might still fail. In that case, one can of course try and do the same with _someone else_ who might be more receptive. This is possible with free/open-source software.

What you consider a "snarky retort" is just the same thing said in a different tone.

</comment></comment></comment></comment><comment><USER106> A word to the wise. Don't read the reddit thread around this. A lovely little snippet:

> > it's up to you as a developer to vet your dependencies

> This is effectively impossible on an individual level, and it's something > that absolutely needs to be a community-level effort.

Don't hire this person... Dependencies are absolutely, FULL STOP, your responsibility. YOU are the one making the money NOT the maintainer.

</comment><comment><USER107> I would feel sad for the creator but after reading more about this it feels like they were clearly acting with malicious intentions, such as removing a bug report from months ago because someone mentioned it in an article, or being rude to contributors.

I do not believe that anyone is entitled to free features/bugfixes/etc on foss projects but apparently this is not what happened in this case.

</comment><comment><USER108> This is the reason why Rust will never go mainstream. People say "You can get the same performance and features as C++ with unsafe!", but as happens in every language such hacks gets ostracized by the community and therefore basically unusable. So instead we just write our code in C++ which is unsafe by default so nobody complains.

<comment><USER78> Nothing whatsoever was "ostracized" in this case. A fix was provided for code that could cause UB in some cases, the former maintainer rejected the fix as "boring" and denied that a problem existed. This could have happened just as easily in C or C++ code.

</comment></comment><comment><USER109> How is this a story?

If people don't want to use an unsafe library, don't. If their patches aren't getting merged, clone it.

If reddit is being meany-heads, don't login.

I really don't understand what the point of this post is. It's arguable whether there's a problem, and if you take the author's point that this is a problem, no solution is offered.

</comment><comment><USER110> The free software and open source implicit contract is that as a user you're free to fork and redistribute. That's it. You cannot force others to accept your patches, or to behave in the way you want. Just fork and create a safe- and-community-friendly version of the project if that's what you want.

</comment><comment><USER111> There's a tendency for masses of people to eagerly follow strongly-opinionated people. I think such qualities are a big warning sign, especially if they're dramatic, engage in all-or-nothing thinking, unconvinced by evidence and/or put their ego / being "right" ahead of everything and everyone else. Furthermore, there's a tendency for people to get emotionally-attached to "their baby/pet" project and reject anything that doesn't fit with their delusions of grandeur. IMHO, assertive, honest, respectful and professional folks who lead projects tend to attract better quality contributions and sustain development long-term than jerk dictators for life who may ragequit at any time if they don't get their way.

</comment><comment> compiler-guy This problem wouldn't exist if the people who wanted changes were willing to write a big enough check. If you get your code for free, you shouldn't expect _anything_ of the person giving it to you. They have already given you more than you are entitled to.

</comment><comment><USER112> You can submit patches upstream all day long, but you can't browbeat the maintainer into applying them if they don't really care about it. It's their project at the end of the day.

Likewise, it's just as annoying when you submit a PR on some random thing because you see a legitimate bug or unhandled case and the maintainer starts demanding you do more free work for them to do 100% they way they would have done it. Just say "thank you", accept it, and make those superficial edits.

The price point here is free. This is essentially a gift economy. Just because some random strangers on the internet have an interest in the same few bits of code, doesn't mean there is an obligation to do free work or twist someone's arm.

</comment><comment><USER113> The article mostly consider both side and the main point is to flourish open source community, which is highly appreciable.

I think, as an outsider, both side had its wrongs and corrects, the author could consider changing unsafe code and the community could be at least civil.

As a personal opinion, i can say that we have to consider the fact that the authors of open source software are mostly doing it for hobby or fun. And if we ever want to keep open source alive and magnificent, we should be very civil and and at least thankful for the programmer and their time.

The only way out i see that could solve the issue was to fork the project and do the desired changes there. I dont know why they did not do that when it got to that point.

<comment><USER5> > I dont know why they did not do that when it got to that point.

I think most people kept hoping they weren't at that point, and could actually move forward without forking.

</comment></comment><comment><USER114> I'm just a js dev with a whole lotta love for the web. I know enough to respect the hell out of Rust. I'd just like to offer my best wishes to the Rust community, and put a call for folks to be more civil on places like reddit, etc.

In closing, here's a nice little gem from the OP author's final blog post on his old blog[0]:

> if there's one thing I've learned from writing software, it's to blog about > error messages.

Cheers.

[0] [http://blog.steveklabnik.com/posts/2015-07-05-ember-data-- ds...](http://blog.steveklabnik.com/posts/2015-07-05-ember-data--ds-is-not- defined)

<comment><USER115> > if there's one thing I've learned from writing software, it's to blog about > error messages.

I hope I'm not the only one who just realized that "A Sad Day for Rust" is also an example of "[blogging] about error messages" and appreciated that statement even more.

</comment></comment><comment><USER116> Hopefully someone with a clone of the project can spin off a "reactix" fork.

I don't think the negativity was necessary, that said, if it wasn't a significant impact to performance but did potentially improve safety, many of the patches should probably have been brought in.

Personally, I've been more drawn to the likes of Rocket and Yew. The former for the server because I really like the interfaces and usability. The latter, I haven't done much with, but think it's pretty cool and a relatively small starting point for a WebAssembly based UI experience, compared to say Blazor.

</comment><comment><USER117> That's my experience too, particularly lately. Reddit/HN both is and isn't the Rust community, but everyone there is a disaster for all the reasons the wider programming world is a disaster.

</comment><comment><USER118> As a maintainer of a medium-ly popular library that I also use for work I can say that I love getting (quality) bug reports since these are bugs I didn't know I had. OTOH pull requests for the bugs I'm not as excited about. I wrote my library with a strong vision for the api and how everything fits together. Many times the pr submitter isn't aware of the vision nor has taken the time to understand how everything fits together. I'll read and understand the submitted code but many times I'll end up writing the fix myself.

</comment><comment><USER119> It is indeed a very sad day. Personally I enjoyed being a small part of this community and amazed how welcoming and constructive it was. But yeah as we grow, we are bound to face this.

</comment><comment><USER120> The guy has absolutely 0 obligation towards anyone. There was 0 money exchanged, there were 0 contracts signed, he's free to take his ball home.

Hope the people who caused this are happy now.

</comment><comment><USER121> Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be ready fuel and kindling for these sorts of social conflicts.

<comment><USER28> What is your alternate proposal?

<comment><USER121> The proposal that has the most concrete chance of succeeding is probably to formalize some of Miri's behaviors as _auditors_ [0], explicit syntactic annotations which indicate a type/function's willingness to have its source code inspected and have facts proven about its behavior.

In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase.

I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better.

[0] [http://www.erights.org/elang/kernel/auditors/](http://www.erights.org/elang/kernel/auditors/)

</comment></comment></comment><comment><USER122> > Can we reject the idea of a BDFL? Can we include as many people as possible? > Can we be welcoming to folks who historically have not had great > representation in open source? Can we reject contempt culture? Can we be > inclusive of beginners?

I feel like in any language, beginners are more than encourage to write things in said language. Yet when working on language internals, you need to be more careful. Reading the Firefox programming guide on what's allowed/not-allowed in the C/C++ codebase is pretty eye-opening[1]. Have there been issues with core Rust developers not being kind or following their CoC? The author doesn't really include examples or explore this line.

As far as Reddit: I stopped using it the moment one of their CEOs altered someone's comments during the election and was not asked to step down. That CEO is still there. Reddit had their warrant canary removed years before that. All their original values are pretty much gone and they've gone on a community banning spree over the past few years. It's also no longer open source. I'm fine with any community rejecting this as any kind of official communication platform, but no one is stopping enthusiasts or hobbyists from using /r/rust

If actix-web has unsafe code and the authors are not accepting patches, and someone feels passionately about it, they could create a saftix-web fork, include all the patches, and maybe even develop it independently or pull in changes from upstream.

It sounds like things went down terribly, and that's sad. Was it just Reddit people, or core devs? I agree it doesn't help to attribute blame, but the author doesn't dive into where the problem might have started and what could have been done differently. I wish this had some more explicit examples of how the community screwed up, the things they did right, the things that could have been better. But then again, that could lead to call-out culture BS. I feel this article is missing some depth, but it's also something that would have probably washed over without the author going out of the way to write this piece. I dunno. /shrug

[1]: [https://firefox-source-docs.mozilla.org/tools/lint/coding- st...](https://firefox-source-docs.mozilla.org/tools/lint/coding- style/coding_style_cpp.html)

<comment><USER78> > I stopped using it the moment one of their CEOs altered someone's comments > during the election and was not asked to step down. That CEO is still there.

That was not a CEO but a _founder_ , AIUI. Can't really fire them or ask them to step down, they literally own the place.

</comment></comment><comment><USER123> I don't know the minute details of the case so sorry but this comes to mind:

The double edged sword of open-source: We can't cooperate with one another if we don't know how to behave and deal with other people. Emotion can never have the final say. Because emotion is raw, uncontrolled, knows no boundaries, doesn't know right from wrong. Especially if it is selfish emotion. Those that act like this are bound to harm themselves and others;

</comment><comment><USER124> > So, someone takes a peek under the covers, and 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. This is where things start > to go wrong.

Can anyone link to a discussion in which the actix-web maintainer explains his position at a technical level?

The article leaves me baffled at why the maintainer was so unreceptive to concerns about the use of unsafe.

</comment><comment><USER125> A lot has been already said about this unfortunate situation. I would like to mention that pinning all this on brigading by reddit is very disingenuous. There was a lot of hate directed towards actix and Nicolay on twitter by some very prominent members of Rust community also who were discussing removing actix from the awesome-rust list so people stop using it. Let's not represent a community by their worst members.

</comment><comment><USER126> I wonder if there is a better way to manage vitriol for Open source maintainers. Why should a maintainer take brunt of other communities responses for issues like this compared to what they've contributed.

There just has to be a a way to summarize the noise such that it is indicative of pushback. There has to be a way to have a discussion without attacking each other when the disagreement is only on a detail.

</comment><comment><USER127> This is what happens when you get attached to a language, a library and especially an idea of how things could be different.

You inevitably get disappointed. Good. Now you can evaluate and see if a different outcome is even theoretically possible.

When you hope, you lose :) It doesn't mean you cease hoping, it just means you don't do it so strongly. It's too much. You know it's too much, so just let go :)

</comment><comment><USER128> > Its author also works at Microsoft, and suggested that Microsoft is using > actix-web in production. This was really exciting to people. This was the > second project using Rust at Microsoft, and so this seemed really fantastic.

Well if the project isn't FOSS anymore I can't see Microsoft continuing to use it, which makes me question the accuracy of this statement in the first place.

</comment><comment><USER129> I liked actix and did a little free time unfinished project in it, when it was updated frequently. Ultimately I lacked the energy to read anew the tutorial and update my code. Still, I liked to use it and think it probably became better over the time I did not use it.

I don't know what kind of licence actix-web had. Seems to have been some open source license and not a free software license, according to the "postmortem" readme file, where the author says: "I am done with open source."

What stops anyone from using a fork to develop further? Did the license not permit that?

If somehow that was not permitted or not possible, because no one created the fork before it was moved to "private repos", then I think the author did something quite childish , taking away the possibility for others to continue developing the software, just because he is fed up with enduring the criticism. "You don't like how I run the project? Meh, I'm going to take it all away from you!" (That's how it sounds, when you move a repo to private after and because of criticism.) Ideally any author, who works on an open source project, knows, that they give up some control over the code and would not act this way.

I do not say, that the shit storms were justified or good in terms of their social aspect. However, if all of this managed to make actix-web safer, then at least that aspect was a good result.

</comment><comment><USER130> I have to wonder -- is this a real problem in the Rust community? The essay makes it sound like it's just the usual Reddit toxicity.

<comment><USER28> That's what I was trying to get at with the "is /r/rust part of the community or not" bit. Inside official spaces, none of this happened. If you don't read Reddit, it follow certain folks on twitter, you wouldn't have seen any of this.

</comment></comment><comment><USER131> There's a false expectation that if a package or project is open source then the maintainer should put in free labor to keep it up-to-date. If you don't like something then fork it and make it yours. Nobody is entitled to anything. If I were the package maintainer I'd most likely do the same if I were getting that kind of response from the community.

</comment><comment><USER132> It's easy to get any bug fix you want: pay for them.

If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you.

(Unfortunately, I can see from reading the comments that not everyone is getting it.)

Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long hours, for free, in perpetuity, prioritizing issues based on reddit heat, and see how many developers agree to those conditions. Those are the expectations that appear to have driven this developer to quit their project.

BTW, for those that don't know: acting on bug reports and accepting pull requests is often a lot of work in its own right. Bug reports are often vague, incomplete, contain incorrect assertions and assumption, lack clear steps to reproduce or even a clear description of what happened vs what was expected. It takes time a effort to clarify these things. Even then you may need to, e.g., build an environment to reproduce or correct the issue. Changes from developers that aren't highly experienced with the project typically have gaps, new bugs, misunderstand requirements, don't build, ignore style conventions, lack unit tests, and have various other issue that have to be ironed out before the change can be accepted. It's all a lot of work.

<comment><USER133> I want to preface my comment with "I agree with you"

However, in this case patches and reproductions were submitted and rejected as "boring". Whether the author really meant to use the word "boring" is neither here nor there, the result was that the fix was ignored, even though that's how open source works!

I've watched from the sidelines with no skin in the game (I use Rocket) and my conclusion from all of this is that the maintainer should have created an actix committee or group of maintainers to help shield from the inevitable bugs and issues that crop up. If the OG author wanted to step back to take a break from all of this, then fine, the rest of the group can continue to churn and work.

The original article that called out the behavior also called out other incredibly popular crates, like reqwests, for their underlying HTTP stack, yet there's not a shitstorm about those libraries. The obvious difference that I can see is the maintainer response to said criticisms.

EDIT: I also want to make clear that I _hated_ the comment about never writing rust again. I'm not condoning that behavior at all

<comment><USER132> I think you're still heaping unwarrented expectations on the developer.

E.g, "...that's how open source works!"

That's your opinion, but what obligates the developer to adhere to this?

If the question is, was this a professionally run OSS project I would say, certainly not, and I assume almost everyone would agree. But so what? Why should a maintainer be expected to run an OSS project to a certain level of responsiveness or spin up a governance mechanism if they can't do it on their own?

> The obvious difference that I can see is the maintainer response to said > criticisms.

I would suggest that reddit mobs are almost entirely capricious, random, and irrational.

<comment><USER133> If my comment implied that there was some sort of expectation then I think there was a miscommunication. There's no obligation for anyone to do _anything_ , ever, but that's a pretty useless metric to mark against IMO.

Was this a professional project? Absolutely not. But was this a personal project? I would also say categorically "no", since it wasn't scoped under his personal github profile until recently. I'm very saddened to see something that could have been solely community maintained be revoked instead of there existing a potential mitigation plan in place (for example in the form of a foundation or Org) for situations like this, especially since this has happened twice before and it's sadly caused burnout for the main developer. Again, no obligation to do this but why can't I say "man, that's true that he _could_ follow these actions but that's also shitty" at the same time?

</comment></comment></comment></comment><comment><USER134> the amplification of reasonable criticism into harassment campaigns is a major dynamic in the last few years, and it generally ends up pushing people completely offline instead of like, allowing them to improve.

It's in open source but it's affecting everyone who posts their work online, which is to say, anyone doing anything that's publicly visible, anywhere.

</comment><comment><USER135> What is the issue here actually?

Fork the project and un-unsafe it.

</comment><comment><USER136> This situation is the sad and absurd result of two processes going on in the Rust community.

The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of grief for the maintainer of actix and prevented real (but _far_ overblown) code issues from being fixed in a productive way.

But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust commmunity members are conflating two wildly different scenarios together. The first is a library exposing an API which, if used in an unlikely and contrived way, could result in a program using that library containing undefined behavior. Then, since that program has undefined behavior, it could contain a memory bug. If that were the case, someone could potentially exploit that bug to attack a user of that program. You'll notice this is a series of conditional statements - its a funnel of decreasing probability.

So yes, library APIs which can allow UB in safe code - even unlikely and contrived safe code - must be fixed. The goal of Rust is that safe APIs can never cause UB. But people should have a proportionate understanding of the risk profile of these bugs (again: a programmer using this API in an unlikely way could create a program with a bug that could potentially be exploitable). This is a miniscule increase in the _risk_ of another heartbleed, it is not _the same thing_ as heartbleed.

The spark that lit the kindling of the toxic Reddit community was a blog post by Shnatsel, a member of the RustSec team. This blog post didn't get attention here, but I want to take a moment to look at how ridiculously it frames things by examining its analysis of a different project: reqwest (sort of the most standard HTTP client library in Rust).

Here's the link: [https://medium.com/@shnatsel/smoke-testing-rust-http- clients...](https://medium.com/@shnatsel/smoke-testing-rust-http- clients-b8f2ee5db4e6)

The fuzz test, which is what the library is about, found no security issues. It found some hangs in 6% of cases and Shnatsel traces them to a known deadlock issue. This is a great result.

But Shnatsel spends most of this talking about a custom hashmap implemented in the http library, which the RustSec group did a security audit of just a few months ago. That security audit found only two issues, both UB that would result from a contrived use of a minor library API (they are linked in the blog post, but not explained). These two issues were fixed, and the fix released, by the maintainers of the http crate in 10 days.

This is an incredible success! The security audit of a foundational library found two minor issues which were promptly fixed, and the fuzz confirms that the entire stack on top of it seems to contain no memory issues. Wonderful result, but how does Shnatsel frame this?

> First things first: it didn't segfault! I am actually impressed because I > had really low expectations going into this.

Come on! The blog post is full of these kinds of snide zingers which are totally unfounded in the face of the actual evidence presented. When you have someone writing in this disingenuous, meanspirited way about open source maintainers and then putting this in front of a groupthinking rage machine community like Reddit, of course you're going to get harassment. This behavior is totally unacceptable, and it's very sad to see it promoted in the Rust community.

<comment><USER78> Didn't the Rust stdlib just gain a high-performance hash map recently? Is there a real case for using a custom implementation in reqwest? I could see Shnatsel getting a bit frustrated wrt. that choice.

<comment><USER137> The reason the `http` crate has a "bespoke hashmap implementation" is not because "performance", it's because _HTTP headers call for different behavior than `std::collections::HashMap`_. Some of the differences in behavior include:

\- The map needs to be a multimap.

\- Insertion order needs to be preserved.

While `std::collections::HashMap` is an excellent HashMap, it is not a good fit for HTTP headers.

</comment></comment></comment><comment><USER138> This is something JavaScript does better than Rust. I like the JS community because it's way more sympathetic on average. They have lots of code quality issues to solve in some of the hardest ways... But people are working on that, and I think they will succeed eventually, if they haven't already fixed much with npm audit.

</comment><comment><USER139> There is a Code of Conduct. Question: is there a Code of Maintainership.

A document describing the principles the maintainer tries to uphold?

</comment><comment><USER140> The "unsafe" keyword should probably just be called "unchecked," otherwise it is a bit of a misnomer.

<comment><USER141> I think 'unchecked' would be a bit of a misnomer; code inside of unsafe blocks is still checked by the compiler for many things. The borrow checker is even on IIRC.

</comment></comment><comment><USER142> We always look at number of stars or installs of libraries before deciding to put them in a production project. It'd be cool if there was a "percent unsafe" badge that was commonly used for Rust repos. If folks started paying attention to it it'd be harder for unsafe libraries to become popular.

</comment><comment><USER143> People being people. I disagree with both the author's code choices and his treatment. I imagine most feel the same. Rust will be fine. The lessons learned about choosing dependencies wisely and taking responsibility for those choices will be scarce.

Running software is always more of a performance than an institution.

</comment><comment><USER144> Some of us in the Rust community wrote a letter of support for the actix maintainer. In case anyone else thinks what happened sucks and wanted to show support.

[https://github.com/actix-support/letter](https://github.com/actix- support/letter)

</comment><comment><USER145> I think the Rust compiler should write as its final log message "Resulting binary contains x bytes of unsafe code" (or something similar). That way, people are constantly reminded that their code depends on unsafe code, and they can try to reduce that with visible results.

<comment><USER146> 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.

</comment></comment><comment><USER147> A community this large can easily deal with a loss of technical talent. It cannot easily deal with toxicity. Therefore, it seems like a good thing actix and its developer are leaving.

Also, a fascinating Trumpian "both sides have good people" -defense play.

</comment><comment><USER148> I think there might be some cultural aspects at play here too as far as communication style.

</comment><comment><USER149> This is a sad day for open-source at large, as well. I think it's very important to keep having conversations about proper stewardship of open-source projects, until we eventually reach new models that are more fair/reasonable.

</comment><comment><USER150> I'm not sure I agree at all with the author about the air about the Rust community. Rust is an amazing language but the community has always been totalitarian trash. I try to keep as far away as possible from them as I can.

</comment><comment><USER151> I have no knowledge of actix-web. But just starred at the insane high throughput achieved in the world most thorough benchmark test. Just horrible to read about what the author had to go through. But fully understand him.

</comment><comment><USER152> Simple solution: Ignore Reddit

</comment><comment><USER153> " _It's unfortunate that a well-known project had soundness issues. It's unfortunate that the maintainer wasn't receptive to fixing them._ "

What should you expect in this case? What is the best possible response?

</comment><comment><USER154> I don't know what a single thing in this post is referring to, so I'd just like to point out the surreal nature of reading someone very passionate about a bunch of words you've never heard of.

</comment><comment><USER74> 1\. I find the assumption that Rust code is safe a bit overly optimistic. If you're writing network-facing code, security is always an issue to some extent, even if mitigated by language guard-rails.

2\. The actix framework author supposedly did the following things at once:

       2.1 Wrote code somewhat carelessly
       2.2 Wrote and maintained his code alone
       2.3 Claimed his code was "safe" - in that mythical complete sense I mentioned above

this combination is a recipe for disaster, and he was warned (albeit in a possibly-non-friendly-way). Thus, while the public outroar is probably excessive - security bugs do happen - he is to some extent getting what's coming to him.

Caveat: I'm a C++ person and am not familiar with the Rust ecosystem.

</comment><comment><USER155> If I was the maintainer and someone offered a patch that didn't alter the properties of my code, but improved it, I'd be more then glad to accept it.

Unnecessary drama because of inflated egos.

</comment><comment><USER106> I want to add two (maybe very) controversial comments.

1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.

Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.

2). Opening an issue and opening a pull request are IDENTICAL requests for effort.

Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.

An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.

I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.

\---

Here is a simple flow chart for contributing to a solo maintainer's open source project.

1\. A problem has been discovered.

2a. I do not know how to solve the problem. -> Move on. Don't reach out to the maintainer in any way.

2b. I can write a fix for this problem but I don't want to maintain this project in its totality. -> Move on. Don't reach out to the maintainer in any way.

2c. I can write a fix for this problem and I want to maintain this project in its totality. -> Fork it. Don't reach out to the maintainer in any way.

<comment><USER78> A maintainer that you can't reach out to is no maintainer at all. If that's the behavior they expect from others, they should clearly state that the project is _not_ being maintained, and be open to others taking up that effort instead.

<comment><USER106> > they should clearly state that the project is not being maintained

A project by a solo, unpaid author should be presumed unmaintained.

</comment></comment></comment><comment><USER156> I cannot help but to think there are deep parallels between software projects and any good old company. Dealing with a group of people around an "idea" is far from easy.

</comment><comment><USER157> This whole affair makes the Clojure way of relying on libraries instead of frameworks really appealling to me. Frameworks are not fork-friendly.

</comment><comment><USER158> The Rust community is very, very toxic. They fight internally, but externally, they take over any thread about anything and make it about Rust.

<comment><USER159> Was here to post something along this line. The only place in which I'm (hopefully) in contact with the Rust community is here. What do I see all the time?

\- "rewrite it in Rust" kind of posts on a lot of threads

\- upvoting Rust mildly or not interesting projects just because there are written in Rust

\- down voting every comment that even slightly criticize Rust (this comment will be gray when you'll read it) or remind that code safety exists in VM language for decades

<comment><USER158> I am _very_ productive in GC languages. I use F# and C# all the time, and the code runs fast, everywhere. And I don't have to worry about memory, and don't have to learn a wacky syntax and wait for hours for a "borrow checker" to complete its static analysis.

<comment><USER160> > and wait for hours for a "borrow checker" to complete its static analysis.

The borrow checker is actually fast, the part where you wait for hours is the code generation. There is nowadays also a "cargo check" command which stops before the code generation, which you can use when you want only to see if it would compile without errors (without waiting for it to actually compile).

</comment></comment></comment></comment><comment><USER21> What's wrong? There was a popular but dangerously broken library, and the maintainer didn't want to fix it, and so it shut down. Everyone is better off now. The code is still free for anyone who thinks they can fix it. It was a bit messy along the way because people get emotional about bad security, and people on the Internet have freedom to make comments you are free to ignore. This is an open source success story.

</comment><comment><USER161> I wonder if some devs will get fired/some startup bankrupt, for using such a risky dependency?

</comment><comment><USER162> Just because maintainer quit doesn't mean the project is dead. It can be forked and fixed.

</comment><comment><USER163> I'm starting to really wish reddit wasn't the default community forum for everything.

</comment><comment><USER164> Dudes, why don't you just fork the repo and run with it. License looks good.

It doesn't matter if code is full of secbugs, author doesn't like patches, or whatever. Code is open source. You can't make it look like your vision. Fork it.

Of course, no one in the mob appears to have had the wherewithal to do that.

</comment><comment><USER165> Man... Wouldn't it be great if this same attitude often seen in users of open source software was had by regular people toward civil liberties? Like where people just pile hate on the codifiers day in and day out, because they are owed their entitlements by birthright.

<comment><USER166> That's kinda how politics works. Sorry to have to tell you :(

<comment><USER165> You didn't understand what I wrote. To put it into simpler terms: Over time, people demand less and less about their civil liberties, whereas with open source projects, people demand more and more.

<comment><USER166> that's not even remotely true.

</comment></comment></comment></comment><comment><USER167> I hope this makes it to the top so ngate can write about it...

</comment><comment><USER168> First the "rust being a moral programming language" and now this - I've never seen a community stain a language so poorly as the rust people. Wow! And I was there when Zed Shaw Cale's rails a ghetto.

</comment><comment><USER169> Why is this getting so much drama?

</comment><comment><USER170> This is my from-the-outside-looking-in take on the matter.

It seems to me that there's a clash of expectations/worldviews, both happening in this thread, and in the wider portions of the interwebz involved in the kerfluffle this article is about.

A comment[1] from ddevault states two things:

> 1\. YOU are responsible for your dependencies.

> 2\. Open source participants are volunteers and owe you nothing.

The above is true. But there's another aspect here, that of cultural norms, implied goals and the expectations derived therefrom.

By my observation of mailing lists, hacker's blogs, my own attempts at contributing to various projects, and other things, there's come to be a set of expectations of the authors, maintainers, contributors, and even to some degree, users, of FOSS projects. These expectations are not set in stone; they can be shaped by the statements and actions of the maintainer(s), implicit or explicit, or the lack thereof. But there is nonetheless a default set of expectations. A set of social norms, if you will.

One of the expectations I've observed, and discovered I myself had absorbed through cultural osmosis, is thus: A maintainer should make clear what a project's goals are, and earnestly consider patches/pull-requests offered in good faith support of a project's explicit or implicit goals. They should communicate clearly technical facts, concerns, and considerations when discussing or debating an offered patch. Said discussion should be focused only around the technical facts as they relate to the goals of the project and the offered patch. And if the patch is rejected, the maintainer should clearly communicate why. Said communication could be a long essay expounding on the technical trade-offs the project has had to make, or a simple link to a FAQ entry covering why such-and-such common patch type will never be accepted. (In that latter case, presumably the earnest consideration of that patch type had happened sometime in the past).

A related norm, one tying back in to ddevault's post, is the contributor's end of that exchange. One offering a patch should accept a rejection with grace. A contributor can and should be willing to discuss and debate and try to persuade a maintainer how the offered patch actually does align with the project's goals after all. But he should do so only with technical facts and logical argument, not fallacies, emotional manipulation, name calling, threats, or other such juvenile BS. To persist and pester after a final decision has been made is a violation of that norm. Thus, it is as equally gauche for a contributor to tell a maintainer to die in a fire after a rejection as it is for a maintainer to state he doesn't accept patches from people who voted for the Labor party in 2017.

None of the above invalidates ddevault's assertions. However, IMO, social norms serve as a sort of oil on the machinery of the human interaction inevitable in collaborative projects. A person rightly gets upset when those social norms are violated. But, there are right and wrong ways to respond.

From what I've seen of this kerfluffle so far, it is a violation of those norms which led to this mess.

Recall what I said about a project's goals, above. Rust's explicit goals of memory safety, thread safety, etc, IMO carry with them an implicit goal of making for secure programs, by making it easier to avoid the kind of mistakes that cause programs to become insecure. I'm not a rustacean, but it seems to me that at least part of the wider Rust community is working on making that implicit goal an explicit one. And so, by building your project with Rust, that goal of a secure implementation transitively becomes one of your project's goals, at least implicitly. If it's not, you had better explicitly state otherwise. And if you do, I don't think you should be particularly surprised when some push back.

And so we come to the violation of social norms. I can't find any before-the- kerfluffle articulation of actix-web being a for-fun project. So, actix-web was seen as having the goal of being sound and secure, by virtue of being implemented in Rust. And here was Nikolay's virst violation: failing to make clear the goals of the project. If after that first instance of 'unresponsive maintaner', as steveklabnik puts it, Nikolay had made clear his main goals were being fast as possible and winning the benchmarks, that soundness and security were non-goals, and he had firmly and politely held his ground on that, I think the kerfluffle could have ended there. If he'd made those goals explicit then, then other users would have been able to take a look at the project, and see that all that Unsafe code was probably not something Nikolay cared about changing, and so know they need not offer patches for it.

But since that wasn't done, we come to the next violation: not earnestly considering those patches offered in good faith -- or at least seeming to. Because of the impedance mismatch between Nikolay's actual goals and those seeming goals of actix-web, he seemed to not take seriously those patches offered.

As I said above, there's a right way and a wrong way to respond to such things. And sadly, the response by some was to violate the contributor's end of the bargain: accepting a patch rejection with grace. By responding with out-of-line remarks like "please stop using Rust", the quality of the discourse degrades, and shit rapidly gets toxic.

I don't think it would have been a violation of norms to call out all the use of Unsafe, and the various ways it was unsound, or even to advocate that others should not use actix-web, so long doing so stayed fact-based and did so somewhere other than the actix-web bug-tracker. As far as I can tell, the smoke test of HTTP clients did that. I haven't dug deep into the Reddit thread, but if there was personal attacks on Nikolay, I'd not be surprised.

What have I learned from this, despite not being part of the Rust community? Well, if nothing else, it highlights the importance of clear communication. In any future projects, I will need to make what my goals (and non-goals) are as clear as possible. I will also need be willing to clarify things when there seems to be an impedance mismatch between my goals for a project, and what a contributor thinks they are or should be. And I'm going to have to develop a thick skin and the ability to de-escalate, because some people are going to respond with perceived rudeness from me with deliberate rudeness of their own.

Perhaps that's a naive take on it. I welcome suggestions on how to improve it.

1\. [https://news.ycombinator.com/item?id=22075346](https://news.ycombinator.com/item?id=22075346)

</comment><comment><USER171> I deleted the issue - I regret that. I'm deleting the project.

</comment><comment><USER172> Oof magoof

</comment><comment><USER173> I agree with what another person has said on github- the rust community on reddit is incredibly toxic. The last time such a thing happened, there were losers who made personal attacks on Nikolay. Then Nikolay showed up in comments being angry that he had helped that particular loser only a few days back.

Its easy to create blog posts and comments about RIIR, its not easy to actually write code.

If anybody actually wants to fix this issue and prevent it from happening again, I'd start by instantly banning /r/rust users for 3 days anytime they do a circlejerk.

<comment><USER4> Blaming 86k people for the actions of a few is toxic.

</comment></comment><comment><USER174> I am _disgusted_ by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue.

There are people who forget that open-source does not entitle you to anything (read the fucking license).

Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.

<comment><USER5> > Maintainers of large projects are not even allowed to have a bad day, to > make a brusque comment, or to disagree with a majority -- without someone > trying to stir up a lynch mob. It sickens me the lack of balance between the > work done by the maintainers, and the expectations of random users.

Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production use". They are then more than free to close issues with comments like "Hey I'm researching a new refcell implementation, thanks for finding this, but I'm more interested in speed than safety at this point."

Actix did not put up a disclaimer, and in a lot of cases, either closed issues/patches without comment, or with a somewhat demeaning comment. It was not just published as a fast and safe production ready web framework, it was promoted as such, so the author should expect patches in that vein.

There were multiple bad actors involved here, but it stems from a maintainer who took issue with anyone finding problems in his code.

<comment><USER65> Sorry, it doesn't work that way, come on github isn't intended for production unless specified otherwise. The default assumption is "This is just some code I don't own". Even repos that do make some claim of support or quality should be treated with suspicion. The onus is on the person using the Open source project to do due diligence.

<comment><USER115> But it's not just "code on github". It has the very professional-looking [https://actix.rs/](https://actix.rs/) and so on.

</comment></comment></comment></comment><comment> Brave-Steak All discussion I saw about the issue was quite civilized.

[https://old.reddit.com/r/rust/comments/epzukc/actix_web_repo...](https://old.reddit.com/r/rust/comments/epzukc/actix_web_repository_cleared_by_author_who_says/)

[https://old.reddit.com/r/rust/comments/epoloy/ive_smoketeste...](https://old.reddit.com/r/rust/comments/epoloy/ive_smoketested_rust_http_clients_heres_what_i/)

I get that people hate Reddit around here, but pushing this on them as vitriol by the Rust community there is wholly unfair. The impression I've gotten is that the developer of actix used unsafe too much, made no attempt to inform users that his framework was thus not safe to use (to the level expected of a Rust project), and rejected plenty of PR's where these issues would've been fixed, while being belligerent about continuing to write unsafe code.

[https://cdn.discordapp.com/attachments/648807492931026953/66...](https://cdn.discordapp.com/attachments/648807492931026953/667520639455854593/img-2020-01-16-160126.png)

He'd even started deleting comments and entire issues just for pointing out unsafe code. _And_ it seems like he's had the archives deleted, since the archived pages which used to exist are no longer accessible (I didn't even know that was possible?).

[http://web.archive.org/web/20200117043715/https://github.com...](http://web.archive.org/web/20200117043715/https://github.com/actix/actix- net/issues/83)

Frankly, after years of seeing people defend C/C++ projects because "well, just get better", I think it's a good thing that security-consciousness is at a point where developers are being rightly criticized for playing fast and loose with security. There are always complaints about how we have no idea what kind of code being used on NPM or other package systems. But make some effort to improve it and now they're the bad guys? Oh, come on. You can't have it both ways.

And as somebody else has already pointed out, plenty of other projects also had PR's regarding safety issues, as linked by the original article which tested all these projects. The actix author is the only one who rejected them, and he's the only one facing complaints.

<comment> Brave-Steak Found a working copy of the original Github issue: [https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...](https://gist.github.com/mafrasi2/debed733781db4aba2a52620b6725adf)

Aside from maybe the second to last comment, I don't see anything here that deserved deletion.

</comment></comment><comment><USER175> Open source is fundamentally wrong and in need of a correction. It's an exploitative labor practice.

There's a better way. It's coming.

</comment><comment><USER176> So much for the C killer huh

</comment><comment><USER177> > Rust has a necessary feature, unsafe, that allows you to escape Rust's > guarantees. This is a really important part of Rust, but also a very > dangerous one, hence the name. But one of the things that's important about > it is that, since unsafe means "I have checked this code, and it upholds all > of the guarantees the compiler cannot check," you can build a safe interface > with unsafe guts.

This blew my mind. I had no idea this was happening! I really hope Rust continues to evolve. Still no idea why JetBrains wont adopt it officially like they did Go.

<comment><USER28> JetBrains does sponsor the development of the Rust plugin, IIRC.

</comment></comment><comment><USER178> Nothing "sad" here. FUD article. By 2 reasons framework was not good enough for usage anywhere else than benchmarks: 1) careless attitude to security issues; 2) too fragile behaviour of author - when I know author can completely ruin some dependency of my project just because somebody on Reddit was too rude, I will never pick such dependency. Internet is a wild place, Reddit is a wild place, deal with it. Creating issues for so many users of your project just because somebody wrote offensive comment on Reddit - I can't even understand such childish behaviour.

</comment><comment><USER179> I dont know what people expected from him, he was working 12 hour days already. If they didn't like it then they could just try to help him out instead of tearing down the work he was doing. Did he not accept PR's because he didn't have time to get to them all? Either way, writing an article further isolating him for all his work isn't going to make the situation better.

</comment><comment><USER56> That's okay, Rust should never be used for web anyway.

I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of _any_ of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, unnoticeable error can lead to devastation. Like running across of a field of sparse landmines, eventually you will get destroyed.

<comment><USER180> The set of all computer programs is countable, so I don't think there can be uncountably many ways to have memory errors.

<comment><USER56> That seems right. Memory errored programs are a subset of all computer programs.

The possible runtime states of a program (expanding every branch/subroutine recursively over all threads) is uncomputable. (Otherwise we would have a solution to the halting problem and be able to correctly free memory at compile time.) I'm not sure if that's the same as being uncountably infinite. It's probably a different concept.

<comment><USER180> Uncomputable is indeed a totally different concept from uncountably infinite.

</comment></comment></comment></comment><comment><USER181> I actually think the "code of conduct" culture that Rust embodies exacerbates this kind of drama. Ironically, it creates a more unsafe environment where everyone feels anxious and judged by the CoC Police. Under the CoC, I am entitled to a wonderful experience, and if I don't get it, the culture has failed in its commitment to me.

<comment><USER182> I have literally never felt "judged by the CoC police" in any project that has one. I have no idea why you would ever feel that way. Pretty much every CoC says "do not be a raging asshole". I am fully capable of not being a raging asshole, and if I slip up and am, I would be happy to be told off for it.

<comment><USER183> There have been very public instances of it happening, though the truth is people would have been just as assholish with or without one. Toxic people don't need to hide behind a CoC to be toxic, and they aren't especially likely to obey one either.</comment></comment></comment>