Sadly, the actix-web maintainer has quit. Check out the repo - it's gone. He moved it back to a personal account and may delete it entirely. He's not just done with actix-web, he's done with open-source. Way to go, team.
It's kinda like last time around. The underlying issue is a legitimate technical concern regarding soundness and unnecessary usage of unsafe in the library, which the maintainer does not perceive as problematic.
Enter Reddit, enter vitriol and toxicity. Real technical concerns, and an utter inability to discuss them like everyone involved is actually people. It's endlessly frustrating. I'd quit too, and now everyone loses.
Steve Klabnick says it better than I could. In his conclusion he observes: "The Rust community says they’re nice but they will harass you if you use unsafe wrong." Can we do better?
I don't know. What do we do about this? What can we do about this, what should we do about this? This is why we can't have nice things, but I really want some nice things. However you feel about soundness, this is a quality piece of software and a big loss for the Rust community and ecosystem.
I'm not mad, I'm just disappointed. Like the author says in his post-mortem:
It was fun trip but now is time to move on. Life should be fun.
Photo by James Pond on Unsplash
Top comments (50)
What a shame of Rust community!
Providing the GUN while blaming people using the GUN!!!
Enterprises evaluate a thing not just because it is labeled as SAFE/UNSAFE but the output/performance/usability.
I’m not sure how to see the future of actix-web at present. Seems like it’s found a new maintainer. Hopefully continues — I’m starting a new project based around it for performance reasons. 🙏
Ridiculous behavior by those 'haters' ... to all of them I would, say "get a life", contribute something instead of trashing other people's efforts.
Sadly some of the people who became the haters did so because they tried contributing and felt their efforts were trashed. This doesn't excuse the reddit mob that was definitely over the line and disproportionate, however.
This time around he actually deleted an issue that was receiving personally directed comments.
Everyone behaved poorly, but not proportionately so.
I'm new enough to rust that I managed to completely miss each one of the storms relating to actix as they were happening, and it seems so foreign to my experience with the rust community so far.
Before today, my perception of "normal" in the rust community was that everyone was nice almost all the time, but now reading about this being the 3rd time with the same project, and it's just been perpetually escalating is just sad and disappointing to learn about.
I'm really feeling like I can't and shouldn't "pick a side" with this at all because it does just seem like everyone involved behaved really poorly, as you said, even from the start of it.
The worst part is that this is looking to be visible outside of the rust community itself, and so it makes a stain on both the perception of the language and it's community.
I may not be correct, but this is still generally my perception as well. The subreddit is full of super smart, super headstrong, super opinionated people, though. However, the subreddit is NOT "the community" at large.
It's not about picking sides, really. The correct thing to do for the (correctly) disgruntled was either a) use something else or b) fork it. Harassing the maintainer is unequivocally the wrong road to go down, and no matter how nice the majority is, that behaviour is enough to make anyone think twice about joining the community no matter how valuable their contribution.
This is deeply problematic and symptomatic of a larger systemic issue that needs to be overcome. Every language community is on the Internet, and at this stage of growth PR matters.
Yeah, it's important to also keep in mind that the subreddit is not endorsed in any way by the core team, and I'm not even sure if members of the core team are even on the subreddit.
I'm not sure if it's the best solution, but I've seen it suggested in a few places now that at least one of the systemic issues that needs to be overcome by the language (either through docs, community, or both) is addressing what good and bad usage of
unsafeitself is. Everyone seems to have a different idea of where the line between good and bad is, and that seems to be at least part of the root to the actix thing. From what I've gathered, the reason why it's still up to the discretion of the developer is because the rust team has internal differing opinions on this as well, which is a problem in and of itself.That's just it. I don't think there's any such thing. I think there are "best practices", but if Rust is to compete against the giants, there really shouldn't be prescribed way of doing things. Unsafe is what allows Rust to go head-to-head with C++ & co. I love that people can choose to use it to push performance boundaries or explore alternate solutions to problems, even if I might not want that particular crate in my dependency tree.
There are tools available to inspect the code you're bringing in. In any language and ecosystem, you should audit your dependencies and actively choose. I don't think we should start restricting how people use this core language feature, though, that's a slippery slope. If the core Rust team can't agree, I can't really imagine everyone who uses Rust agreeing, and I think that's a good thing.
I know what unsafe means to me, and how I want it handled in my projects, but if that was the "One True Way" and everything else is taboo, we close a door that I feel would be to our collective detriment.
Don't get me wrong, I wholeheartedly agree that there shouldn't be a specific "One true way." What I understood to be the meaning was just more defined best practices or more examples of when unsafe is okay to use. I absolutely think that leaving it up to the developers is important, and feels somewhat related to freedom of expression in some ways.
What I've taken away from the reactions I've read has been that the rust community needs to chill when it comes to unsafe usage, so having it show up as the escape hatch it's meant to be is a good thing. It's become clear to me from today that at least a good chunk of the community simply views unsafe as a bad thing, which is different from the sentiments I've seen given by the language team that unsafe is as much a language feature as lifetimes are.
So I guess that's more of what I mean, unsafe needs to be brought more to the forefront in a way that it shows off great things that unsafe can be used for instead of making unsafe itself the taboo.
Definitely, wholeheartedly agree. At least in this case, the
actix-webrepo should have had a disclaimer front-and-center on the readme about how this particular project viewed the issue.Ever used a
Vec<T>? Repent! ;)I think that there is some general misunderstanding about all the safe/unsafe deal, because some code is safe doesn't mean it can't fail, just say that there is no undefined behavior, your logic can still be wrong, that's why Rust doesn't mean you don't need testing. So some trust in the developer is still important.
Unsafe in the other hand doesn't mean that there are undefined behavior inside, just that the compiler is unable to check for it.
I don't know the details of what happened with the complainers and the main dev, but I wonder is that if so many people felt so strongly against some aspect of the project and where technically proficient enough to be certain that those unsafe where unnecessary, why nobody offered patches and if they did and wasn't accepted why nobody forked the project, that's how it works isn't it. Also, between 0.7 when I saw this whole mess started to v2 a lot of progress was made getting rid of unsafe code.
I think the main dev didn't manage properly the community and part of them became haters, so no matter what changes where made, it was too late.
Maybe the main dev didn't wanted to work with others, not ideal, but his project, his prerogative. Forking is always an option, sadly I'm far from being able to do something like that.
To me just someone capable enough to fork can critique so heavily and in that case, stop critiquing and fork the damn thing.
I'll be here praying to the coding gods (No Robert Martin, you are not a god) that some organization forks Actix, Rust need some bedrock in this, doesn't even need to be the best, but stable and reliable. Just like in Python, whether you like it or not, you can try Flash, Tornado or whatever fancy new thing, but at the end of the day you can always go back to Django and you can be pretty sure it's gonna be there.
Totally agree with this. One thing I really like about rust is that stuff like unit testing feels really easy to do, even where I haven't really been taught to do testing outside of the debugger and print statements at university. The fact that stuff like this exists for rust alone should be proof enough that "safe" doesn't mean "bug free" and "unsafe" doesn't automatically mean "bug riddled"
As far as the forking stuff, I totally agree as well, but I'm also not proficient enough in rust or ready in general to maintain an open source project. Most of my info with this incident is 2nd or 3rd hand at best, but from what I got, some PR's were made and rejected, which spiraled out of control. They really should have just forked it if it was that important to them.
oh no, don't get a life, they will spread even more their emotional mess. We should make a special Internet, not connected to the main one, just for them to spread their hate, and put a couple of chatbots making controversial remarks and let then have their fun, away from the rest of humanity.
It doesn't even need to be well made, they will hate it anyway.
Haha brilliant :-)
Relevant: Paul Graham - Haters.
Good read. I think we, as a species where never so exposed to so many "variants" of people, before the internet, we made contact with a few hundred maybe a thousand people in our life, and we didn't cross words with most of them, now we are realizing that some "variations" are more "visible" than others.
Sadly the bad experience of the Actix founder where because of 10 guys (somehow I can't picture a woman in that group, maybe is just my poor imagination) making him miserable, while thousands of us where happily enjoying and appreciating his job.
We had, in part, some of the fault, we didn't scream as loud as those 10 sad noisy and envious little people. We failed too, so accordingly we also pay for it. :(
What's most concerning to me is that under the anger there's a real, important discussion trying to get out. The soundness conversation matters when discussing the only 1.0-stable web framework in the entire ecosystem. I'd hope that as a community we can figure out how to actually have the discussion despite these loud few.
Oh yes, and it got muddied but the hatred. I don't know the reasons behind it but the fact that the whole load was taken by just 1 guy is a big part of the problem. Both, all the time before this event and now, even the Linux Kernel that is very Linus-centric have devs that could take charge as a head or as part of a head group, Actix apparently had no such group. I really think that this concerns the whole Rust community, after some lookout I found no real alternative, the closest would be plain Hyper which is much more barebone and Rocket that in all benchmarks doesn't do well (at all) and is still in 0.5 with nightly. Which is leaves Rust pretty much like 2-3 years ago. Even the wasm/rust is threaten because why use Rust for the front end if you can't use it in the backend too.
Even I'm wondering if I should move my Rust efforts back to Python or maybe Golang, which is very sad to me, because I really like Rust. But waiting god knows how long for Rocket to catch up or a couple of years for some other framework to get born and get stable.. tuff
Be the change you wish to see, etc... one slip up does not undo all the progress the community has made, and I think anyone who's bitten the Rust apple believes in the technical merit of the language as a platform, just maybe not necessarily the ecosystem as it stands today. I'm not going anywhere.
but we'll have to see what happen with Actix, maybe someone else will take charge, but the fact is, if disappears I can't sit in my thumbs for who knows how long and sadly technically better doesn't make it viable (ask Haskell programmers).
My main interests in programming in general are embedded and webdev (mainly backend), to catch C in embedded Rust is years away and without Actix webdev seems to be also in the same situation.
But maybe all get sorted and this is a wake up call for the Actix founder to get more hands in the cooking, maybe get someone to deal with the community and him just code, which probably would make him happier (would make me happier).
Is hard to just leave your work of many years, I'm hoping his fingers get itchy. He released version 2 not long a go for Pete sake. Maybe some cold headed chillout put things in order and the blackout shuts the annoying haters and all of us start taking care of them in forums and github discussions.
Maybe this is just a necessary reset. Dramatic and terrifying but necessary.
Would be bad either if Mozilla or some other big dog pay some attention to Actix, because as I mentioned, the whole web backend is nowadays depending in 1 guy and is not a cold hard tuff almost inhuman Torvalds, that scolds Intel for their bugs or give the finger to Nvidia.
Meanwhile, it forced me to make some rework in a petproject tha have some coupled code, some layers mixed up that would make dificult to migrate from Actix to something else. :)
I've dabbled with Rust for a short while because I got involved in a project which used it on the backend - which later stalled, then failed, in large part because of the same sort of psychological/interpersonal issues which we're discussing here - headstrong, 'toxic' en self-centered people, prima donnas. I really had a deja vu feeling, different context, similar problems.
We used Rocket as that was apparently the 'standard' choice, I have no clue if it was good or bad but as far as I could see it worked.
I was (am) a total beginner in Rust but I liked the design and philosophy of the language a lot. It has a very well designed type system, it has a strong FP feel to it, and so on. Haskell but then less academic and more practical, that's how I see it. I don't see it as a better C since I'm not interested in C (or C++) at all :-)
After that I looked at Go and I was quite shocked at how incredibly simplistic the language is. What really sticks out like a sore thumb is the lack of generics in its type system, this means that any form of FP (functional programming) is almost impossible, as a result everything is coded imperatively with repetitive loops ad nauseam.
The good thing is of course its compiler which runs circles around Rust's (but then again the Go compiler doesn't do that much ...) but if Go didn't have its admittedly brilliant Goroutines then I wonder if people would care about it at all.
Sad to say that after that project which I mentioned went south there wasn't much motivation left for me to spend any more time on Rust.
Also a pity IMO if Rust gets framed too much as a "systems programming" language in the C/C++ corner, potentially it could be a very good web/network/backend development programming language as far as I could see.
exactly, that's why I think that Actix is so important, it's the proof that you can make higher level stuff with it; I haven't lost hope on a Actix comeback, if not by Nikolay by someone else. Is too much and to good work to be lost and the Rust ecosystem is small enough that this event will not pass unnoticed. I wouldn't take Actix for dead yet. Imagine how awesome and how fast could Actix grow with a "big" dog behind it, it hasn't even need to be that big, maybe even take Nikolay as head dev and put people to deal with community, minor patches, etc. In a Linus like situation. If him almost alone built Actix in a few years. We sometimes think webdev as just more complex websites, but is also tooling for monitoring, interfaces for embedded, enterprise systems, ERP are basically huge webapps. And with Rust as one of the main wasm PL having a fast and robust backend is vital and now we know it can be done and used even by chumps like me :) and even without a huge documentation like Django, the fact that I can use it just with the API docs is a credit to buth, Rust and Actix.
I'll take a second look to Rocket but the fact that is a 0.5x version and that only works with nightly kills me.
Haters hate because they're frustrated that they didn't accomplish anything significant themselves. In the meantime, there will no doubt be a gazillion forks of actix-web out there, so one of them could produce a new maintainer.
Lets hope someonelse is capable and willing to keep the project alive, is weird that in general the Rust community I've seen is very nice, cooperative and supportive, everywhere BUT Actix. This would be a huge blow the the entire Rust community and ecosystem that is not old or strong enough yet to have loses like this, what do we have in this space? Rocket? seems nice but tha nightly make it not very reliable. Is there other framework available and above the 1.0?
It's a shame, I really enjoyed working with Actix-web.
Let's this be a warning for all of us, and a reminder that if you are not paying someone salary and have a contract, they are not your employee and don't work for you, so let's appreciate and respect those who are willing to work for others.
After all you don't 10 commandment, just 2:
1) don't be a jerk
2) don't play the fool, you know exactly when you're acting like a jerk
Not on stable. I think I've linked it before in a previous thread with you but my sights are on tide - once it reaches 1.0.
oh yes, tide looks really nice but I don't think it will in 1.0 any time soon, but I may be wrong, strangely Rust projects seems to advance really fast, I don't know if is just my impression, but sometimes really surprises me. Actix, Diesel, SQLx, one day is bare, almost nothing and the next month they are packed with goodies, stable and polished. Maybe is the safe feeling of Rust and that they don't spend too much time documenting and making tutorials and alike, once you get used to it you just go straight to the API docs (that are made automagically), I love that too, just reading the API docs you learn Rust.
Even just making mistakes. I learned how to properly use
Arc<RwLock<T>>largely from compiler errors, suggestions, and lints.Actually, I find that a little alarming, @robertorojasr . Even if Rust is the most obvious, straightforward language in the world (which it isn't, at least to me, and that still counts), a lack of documentation always comes back to bite a community.
Case-in-point, Python is famous for being obvious in most cases, often even more so than Rust, but the community didn't take that for granted and wrote the documentation anyway. And it's a good thing. We get no end of "obvious" questions in
#python, not because the language is so bad or the topic is so murky, but because its entirely too easy to overestimate how obvious something is based on our own technical biases.Design so that documentation is redundant. But then document anyway. "Most API documentation is like teaching someone how to use a toaster by explaining the electrical specifications of the heating element."
I actually don't know that I agree with that characterization of the ecosystem outside of brand-new tools that are just starting to see the light like SQLx, and these will catch up eventually if they catch on. In general, I've found Rust core tools and established ecosystem tools to have a very robust, high-quality documentation culture even relative to more established languages. On the contrary, this culture one of the big draws for me.
It's a new language, so there are inevitably gaps, but it's a time issue. I haven't personally felt there's any false sense of security created by Rusts's semantics in this regard. The false sense of security is around what "unsafe" means in the first place, but that's a separate issue :)
maybe that's what has slowed its wide adoption, maybe it also has something to do with my impression that most projects seem to be solo projects (made by 1 or maybe 2 guys); perhaps is because of how new is the ecosystem? I haven't follow a language so young before. Is also worth noticing that even in Python not everything started thoroughly documented, it was a process, when I talk about documentation here, I'm excluding the more technical API docs, those are usually very complete, filled with useful examples, for the standard Rust libraries I never felt the need for something besides The Book and the API docs; when I talk about "documentation" I'm wrongly refering to extras, like tutorials, step by step guides and alike. And those where scarse at best with Flash, SQLAlchemy and even Django always had a very good documentation but at first lack many important topics and many features went undocumented for a long time, with the years have been improved a lot.
We must also notice that Rust is not it's web frameworks and the language didn't aimed to web devs, so documentation is more "technical", there are also web frameworks in C and C++, and don't have all those extra documents either, but to say that C has poor documentation is a stretch.
I also think that, like any other document, it has it's group target, of course if you compare the documentation of Django with Diesel for example, Diesel is light years away, but if you compare SQLAlchemy (a few years ago, I don't know about it now) with Diesel, Diesel's in not bad at all, with the difference that Diesels API docs are awesome and every single thing is documented. Of course the target audience for Django is not the same as Flask, Diesel, SQLAlchemy or Rocket; and Rust doesn't have a Django yet.
I'd say it isn't any more "technical" than Javascript docs are. Yet Javascript docs may feel "technical" to a desktop application developer such as myself, since the industry sector is unfamiliar.
Documentation is geared towards the target audience of the language. Tutorials (and books) are how someone new to the programming sector onboard, mainly because they need to be taught the fundamental paradigms, patterns, and concepts of the sector. Someone already in that sector likely needs no such introduction; a Java developer is right at home with the C++ documentation, a C++ developer with Rust documentation, and a Rust developer with Java documentation. They're operating in the same sector.
I think I misspoke (misswrote?) before, my point was that I've found that in Rust API docs are not bare or just enough to say you documented; for I've seen in Rust API docs are taken seriously and are closer to Python official documentation that a document just for the dev team. Documentation usually is not a separate thing, that someone else does, is closer to the code in the sense that is never out of date and if there is code there is documentation, there are not undocumented bits. I couldn't survive by Django documentation alone, even tho is amazing there was a lot of features undocumented, a lot of times I had to check in the code itself for some edge cases 3rd party docs: tutorials, guides, etc. where frequently necessary; even more so with Flask and SQLAlchemy. That hasn't happen to me with Rust so far.
I think this is exactly right.
I agree - these resources are done extremely well, to the point of replacing supplementary material I've needed getting up to speed in other environments.
I have also found that there's less of this type of documentation in general, but when it does exist it tends to be high quality, and like you say the fall-back API docs are great too. Diesel is a great example, I think their getting started page is well done and they provide other guides too, but it took time to produce after publishing the crate due to bandwidth.
That's a failing of Django documentation, not indicative of a merit of Rust's. ;)
That's why I used quotes, I couldn't find a better adjective.
Was not meant as that, just an example to illustrate that even the better documented SW has it's flaws, those doesn't make them badly documented. Which is of course subjective at some point. And if you read until the end of the paragraph
Clearly I mention Django to illustrate the difference to me between both and that Django is more friendly to newcomers yet somehow incomplete and Rust more complete yet maybe less inviting to newcomers. That's what I meant to target audience.
That's what I mistakenly called Documentation before in opposition to API docs which obviously are documentation too. Of course you need documentation, nobody will use a library and even less a framework looking nothing but the code, that would be insane. Not even if the library is only for consumption of the author, not if expect to maintain some sanity.
Aha, following you now. :)
the interesting thing is, English is my second language, and that shows how, when you are not comfortably enough with the language you end up "coding" big convoluted responses to explain something simple. And misunderstandings happen. And then you try to solve it with more comments. haha, so meta. :D
TODO list:
Whew. From the other comment, I was getting reeeeeally worried.
If it didn't I wouldn't have stuck around. Who has that kind of time?
I have mixed feelings reading this:
On the one hand: There's no excuse for anti-social behavior, harassment, trolling, or flaming. It sounds like the Rust community was out of line.
On the other hand: Open source is open. Unlike closed-source, where you can do terrible things and (probably) get away with it, the inherent project benefit of open-source is that sub-optimal solutions have a better chance of being caught. Refusal to acknowledge a significant problem with one's code comes across as arrogant and unteachable, and rightly so! So, while the torch-and-pitchfork mob was clearly inappropriate, the maintainer invited it by his actions.
On the third hand: Anyone working in open source must grow a tough skin. This isn't because toxic behavior should be tolerated, but rather because unfiltered criticism is a necessary component of growth! As both an author and a coder, I have to be open to feedback from others.
I joined my first professional writing critique group at age eight, and they did not spare my feelings! The other authors were never rude, but they were necessarily blunt. I had to graciously accept even the toughest criticism of my work. That is the only way I achieved mastery of my craft.
On this same point, there are toxic people out there. If I were to crumble at every negative response I get, I'd never accomplish anything. If you can't do anything to mitigate a toxic response, then Get. Over. It. Move on.
In that light, here's what I see:
An open source maintainer fails to understand a critical facet of idiomatic Rust code, utterly violating accepted practice in his library.
Others draw attention to his error, respectfully and constructively.
Maintainer flatly refuses to listen to admonishments.
Community reacts to maintainer's apparent arrogance and unteachability. Mutual immaturity creates a feedback loop. An unruly mob results, in which toxic and unacceptable things are said.
Maintainer's fragile feelings are hurt, and in a temper tantrum, he takes his marbles and goes home. I suspect this was a combination of petulance (apparent in his "postmortem") and shame, the latter because (it would seem) he can't accept that he did something wrong. Since he couldn't deny it anymore, he had to go hide. (Imposter Syndrome)
That is, to quit all of open source in a fit of rage is to admit that his problem wasn't with this particular community; it was with the risk that his work might be critiqued by people who knew more than he did, requiring him to completely readjust his assumptions.
So...
Could the community have handled that better? No doubt.
Is the maintainer justified in quitting, removing his project, and giving up? Not for a moment.
I find one more thing here curious, and that's his parting words:
Such a philosophy is not a hallmark of maturity. Life is not always fun. Projects get hard. Drudgery and routine happen. Difficulty comes. Maturity means you stick it out through the rough patches, only quitting when it becomes clear the difficulties are not going to clear up and are directly impacting your mental health (e.g. Guido van Rossum stepping down as Python BDFL.)
This entire situation is unfortunate, but the Rust community can only take responsibility for, at most, half of it.
While your timeline is mostly correct, I do think it's important to note the degree to which the harassment escalated. It wasn't just an uncomfortable public discussion, he was harassed relentlessly and personally in private messages as well. It spilled over.
You're right, it comes with the territory, but I think it's a little more justified than just a temper tantrum. He wanted the abuse to stop, I think that's reasonable regardless of his role in the origin. That might be your point, though - if you can't hack it, you shouldn't.
I do think maybe "a week off" might have been a viable option... but he's a volunteer with (ostensibly) better things to spend this energy on.
I figured it was something to that degree.
To be clear, I don't think it's altogether unjustified to resign from the project. It was the other two aspects of his response that lead me to classify this as a temper tantrum, not just the abandonment of a toxic situation:
(1) He removed his code. That is never done. The normal response, even in extreme cases such as this, is to resign as the project manager and mark the repository as unmaintained. If someone else wanted to take over Actix-Web, they'd be able to. Instead, he's "taken his marbles and gone home," thereby punishing everyone who has tried to be nice, assist with the project, and generally support the library.
(2) He quit open source altogether. According to his GitHub profile, Rust is not the only community he's involved in, and he cited no issues with those other non-Rust projects and organizations. If he were simply quitting a toxic situation, he'd step down from Actix-Web, and possibly even decide that Rust is not a worthwhile time investment for him; that does not mean he would therefore never participate in any open source project again. Psychologically, that would suggest to me that his reasons for quitting were, again, not rooted primarily in the torch-and-pitchfork mob, so much as in the risk of criticism that he just never learned to handle in any form. (The rejected PRs and dismissal of prior, constructive feedback point to that.)
So, how should he have responded, then?
I like your suggestion first: take time off. Step back. Don't make decisions based on strong emotional reactions. Let the seething angry mob calm down (potentially), and then reassess the situation. That might take a week, a few weeks, even a few months. But don't quit right off.
If the situation is untenable — and perhaps the Rust community is not a good fit for him — then step down from Actix-Web. Announce resignation from the project. Mark the project as unmaintained on the
README.Conventionally, when a sole maintainer steps down from project with an established user base, they outline a process by which someone else can petition to take over. Perhaps, in this case, the ideal candidate would be someone who understands the problems with
unsafebut also has a history of supporting the project. Regardless of how this is done, the end result is the same: transferring ownership of the repository to the new maintainer. It allows the original maintainer to wash their hands of the project and move on to better things.Evaluate oneself. The worst thing we can do in life is to assume the problem is always everyone else. Linus Torvalds, for example, had to recognize that some of the problems in the Linux community originated from his own unhealthy ways of dealing with things, and sought out qualified help on that front. Similarly, Guido van Rossum (apparently) recognized that he could not balance his vision for Python with that of the community, and that it would benefit everyone else to step down as BDFL and only be one of the opinions in decision making, instead of the voice.
Don't. Give. Up. After giving oneself time to cool down, one should explore and find a facet of open source that is a good fit. Learn from the mistakes of the past, and then move on. Maybe the person won't spend as much time on open source in the future, but they shouldn't defenestrate the whole thing.
I don't say any of this lightly. I've dealt with harassment, some of it quite serious, and a large part (retrospectively) entirely unwarranted. I've had to quit communities and projects. I've analyzed my own behavior, and tried to learn what I could from each situation.
We can't control how people treat us. We can only control how we choose to respond.
The other interesting component to this saga is the language barrier. There's no way to know, but I'm curious how much misconstrued tone and intent on both sides of the conversation contributed to how bad it got.
Altogether valid.
Finally some good news, actix-web is back with a new project leader; let's hope everything goes back to normal and now with a more receptive and open development which may attract more devs. Also this whole debacle make me take a closer look to Warp and Tide and those look interesting too. The learning process is painful sometimes and that's good.
Honestly, I’m surprised it doesn’t happen more often
In the repo there is a open issue, "Thank you for your service" github.com/actix/actix-web/issues/4
Maybe is not much, but a little token of appreciation doesn't hurt. Maybe is a little too late but better late than never :)
That sums it all...
I find that weird, this is the only Rust related drama, in fact even the Rust subreddit is very friendly, which is not the norm in Reddit, even people mistakenly looking for the game Rust are cordially corrected.