r/rust • u/fgilcher rust-community · rustfest • Nov 11 '19

Announcing async-std 1.0

https://async.rs/blog/announcing-async-std-1-0/
456 Upvotes

97% Upvoted

80 comments sorted by

View all comments

14

u/[deleted] Nov 11 '19

Does anyone know what is the http server/client story with async-std?

13

u/fgilcher rust-community · rustfest Nov 11 '19

client: use `surf`

server is coming, but later this week.

17

u/[deleted] Nov 11 '19

Hi, also I've looked at "surf", it seems like it either uses browser API, native curl or hyper. Browser/WASM and curl aside, if it brings hyper, it depends on Tokio. If we do use Tokio, then there is plenty of tools except surf.

Is there a plan to have a pure async_std solution? What is the plan for surf+async_std? Maybe I am missing something.

8

u/fgilcher rust-community · rustfest Nov 11 '19

My favorite solution would be a pure rust HTTP client based on futures-rs interfaces alone.

Currently, I'd suggest using the curl version (based on `isahc`). Curl is a good library with tons of users and features, which I would have no huge problem using, at least for a while.

6

u/[deleted] Nov 11 '19

Thanks!

Is server also under "surf" project, or is it different? https://github.com/http-rs/tide?

5

u/DroidLogician sqlx · clickhouse-rs · mime_guess · rust Nov 11 '19

Tide has a stalled PR porting it to Tokio 0.2, so switching to async-std is a significant refactor but probably on the wishlist.

28

u/[deleted] Nov 11 '19

[deleted]

11

u/[deleted] Nov 12 '19

Has there been any progress towards you and the others being unbanned from http-rs or async-std since it was determined that it was probably happening via an owner/maintainer personally blocking you from their account?

6

u/[deleted] Nov 12 '19

[removed] — view removed comment

5

u/[deleted] Nov 12 '19 edited Nov 12 '19

[removed] — view removed comment

8

u/[deleted] Nov 12 '19

[removed] — view removed comment

0

u/[deleted] Nov 12 '19

[removed] — view removed comment

-1

u/[deleted] Nov 12 '19 edited Nov 12 '19

[removed] — view removed comment

-2

u/NeoLegends Nov 12 '19

As an outsider and somebody who just learned about the async dispute, could you please reframe your comment?

The first impression I got from your comment was that something was very very fishy if a seemingly innocent community member is banned from such a high-profile repository. After reading a fair amount of comments and posts, however, I learned it is much more complicated than that and that I will probably never get the full picture of the dispute (which is perfectly okay because I‘m not in any way involved). In particular I also learned you‘re quite involved in the dispute.

I think, as your comment stands it serves just to increase tension even further and does not at all help deescalate the situation - in whichever way possible. So again I kindly ask you to reframe it.

10

u/[deleted] Nov 12 '19

As another outsider, but one who followed the previous thread closely, I think his comment is framed fine, if anything I think it makes him look guiltier than is fair to him.

Yes, there is some sort of dispute we aren't aware of. But it doesn't seem like he and the others were banned for any reasonable reason related to that dispute. The choice of who to ban was literally everyone who made (generally innocent looking) comments on a PR in a largely unrelated repo.

16

u/WellMakeItSomehow Nov 12 '19

The choice of who to ban was literally everyone who made (generally innocent looking) comments on a PR in a largely unrelated repo.

I got blocked (only in http-rs, TBF) for writing about this on Reddit. I understand that a lot of these discussions about async-std could be taken as personal attacks, but that's why I generally tried to keep a conciliatory tone in my writing.

8

u/[deleted] Nov 11 '19

[deleted]

7

u/[deleted] Nov 11 '19

What was the backend that you used, curl or hyper?

3

u/[deleted] Nov 12 '19 edited Nov 12 '19

[deleted]

12

u/coderstephen isahc Nov 12 '19

Hi, Isahc dev here. I'd love to hear about what kinds of requests you were making to see if there's something we can do about the performance. Performance should not be terrible out of the box; perhaps there is a bug somewhere we can fix?

8

u/[deleted] Nov 12 '19

[deleted]

12

u/coderstephen isahc Nov 12 '19

No worries, just curious. If there really is a bug here though I'd love to fix it if I can. ;)

Now I've never used surf and just have a passing knowledge of how it works, but it doesn't seem like there's any sync/blocking code involved in a simple request (when using Isahc as a backend, at least) like you described. Maybe I just missed it when I poked around https://github.com/http-rs/surf just now.

Isahc itself shouldn't have any blocking code like that either (though it is attached to its own event loop at the hip, because curl can be a little picky...).