Skip to content
This repository has been archived by the owner. It is now read-only.

Add tokio as an alternative to romio #106

Merged
merged 1 commit into from Nov 6, 2019

Conversation

@kpp
Copy link
Contributor

kpp commented Nov 1, 2019

async-std was listed as an alternative in #105 although Tokio has gained async/await support some time ago and is used extensively in production

Roman Proskuryakov
@spacejam

This comment has been minimized.

Copy link
Collaborator

spacejam commented Nov 1, 2019

After 2 hours, this issue got 17 thumbs up. After 5 hours, it has 20. I recommend closing this issue as spam.

@kpp

This comment has been minimized.

Copy link
Contributor Author

kpp commented Nov 1, 2019

Maybe these thumbs up tell you that this PR is what the Rust Community is interested in?

@Ralith

This comment has been minimized.

Copy link

Ralith commented Nov 1, 2019

Might be prudent to update the "Relationship to Tokio" section too, since it's fallen a bit out of date with the status quo and would be extra confusing in the face of this PR.

@kpp

This comment has been minimized.

Copy link
Contributor Author

kpp commented Nov 1, 2019

@Ralith will do in another PR after this gets land

@mexus

This comment has been minimized.

Copy link

mexus commented Nov 1, 2019

After 2 hours, this issue got 17 thumbs up. After 5 hours, it has 20. I recommend closing this issue as spam.

I beg you pardon, but are you really serious about this? Just want to clarify

@Fedcomp

This comment has been minimized.

Copy link

Fedcomp commented Nov 2, 2019

@spacejam could you explain how this issue is a spam?

Tokio got async await support in alpha versions. As far as i know neither async-std nor tokio is stable, and this project is tokio fork, so why not update it with alternatives?
In my opinion tokio is more established foundation for async in rust, so it would be fair to note them both into readme.

And why do you call my 👍 spam?

@vorot93

This comment has been minimized.

Copy link

vorot93 commented Nov 6, 2019

@yoshuawuyts could you please clarify the reason for OP's ban in this repo?

UPD: It appears that ALL commenters have been banned from both this repo and async-std.

@withoutboats

This comment has been minimized.

Copy link
Owner

withoutboats commented Nov 6, 2019

I've decided to merge this PR, because there's no reason not to link to tokio, and to archive this repository, because it is deprecated, unmaintained, and of no use to anyone anymore. I am not going to merge #107 because reviewing the wording and stating the relationship to tokio presently is more effort than its worth.

Before I do that, though, I want to comment on the absurd situation of this pull request.

First of all, the users who find themselves unable to interact with this repo find themselves such because the repo is mine and I have personally blocked them from interacting with me further on GitHub. I cannot speak to any situation involving async-std, because I am not a contributor to that project.

I blocked these users because I do not believe they were acting in good faith in making and supporting this PR. It seems obvious that when a minor readme change to a deprecated project receives dozens of thumbs up within hours that something unusual is going on. In the larger context of known tensions betweens async-std (which shares contributors with this project) and tokio, and in my personal context of having found @kpp to be an aggressive and unpleasant person to engage with, what has happened here is obvious to me. That @kpp has gone on to use this PR on reddit to claim async-std's maintainers are not "kind and open" is the most disingenuous horseshit imaginable, one wonders if that was his initial hope for this PR, or just a happy outcome for him.

I have collaborated at length over the last several years with many people who are contributors to both async-std and tokio. There are people involved in both projects that I consider my personal friends. I am aware of the tensions between members of those projects, and I am privy to many of the details of those tensions which are not public - for good reason! - and which most people who see this PR will have no knowledge of. And even the contributors to some of those projects who I find it difficult to work with are, in my opinion, sympathetic at a fundamental level. But the people who have advanced this PR, with the only goal of hurting feelings and reputations, are not sympathetic to me. Why be so spiteful to people you've never met, who just want to write code in peace? What joy is there for you in ruining other peoples' days? How dare you pretend to be acting in good faith on behalf of the community! My code is written for people of better character than you, go away.

@withoutboats withoutboats merged commit 80723ae into withoutboats:master Nov 6, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@kpp kpp deleted the kpp:patch-1 branch Nov 6, 2019
@yoshuawuyts yoshuawuyts referenced this pull request Nov 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants
You can’t perform that action at this time.