Closed rylev closed 3 years ago
Your summary indicates that Alan is writing a library (and so this clearly has links to #49 and #45 as you already mention). But this got me wondering.... if Alan was only writing a binary, would he feel the same levels of doubt? He might not, but I think it's still possible. I wonder if there are any personal accounts of someone so overwhelmed by all the decisions needed to pick a HTTP library that they hesitated using rust for their new binary project
I can definitely imagine getting held up when writing a binary, but it'd be nice if we could cite an actual example.
I think this is also relevant in the binary case but perhaps less than in the library case. In the binary case, the choice impacts only the code you (and those working with you will write), there's no need for down stream considerations. In such a case picking a concrete HTTP implementation can be easier as you "just" need to make a choice that works for your project. In the library case you need to accommodate all possible uses of your library that you want to support.
Hello,
Do you intend to cover usage of HTTP libraries for building HTTP micro services within this issue, or you plan a dedicated issue for that too, or do not intend to cover web services at all ? I believe async is at least as much relevant server side as client side.
I don't know the background and scope of the personas in this story but, if I may, I'd like to extend Alan's story a little bit because the situation is even worse than in the first description. This story is a bit different in that Alan is not writing a library, but assessing the feasibility of Rust as a language ready for the web (this is a HTTP story after all!):
async-std
and actix-web is written for tokio
.reqwest
HTTP library
is a bit generic, does it include http client libraries, servers, both?My initial read of @rylev's summary is mostly about choosing a http client library, and doesn't go into using that library (though this is an obvious next step).
A lot of Alan's pain that I see in your comment @cortopy is perhaps reflected in the Alan started trusting the Rust compiler, but then... async story. Do you think this story covers the experiences you outlined above?
This sounds very similar to that story indeed, though it highlights some different causes for pain-- in particular it seems to be touching on version incompatibilities as well.
The story is about selecting an HTTP client implementation in an application where HTTP is a minor implementation detail and very much not central to the application itself. What is a simple choice in many languages is not simple in Rust. In fact, @cortopy seems to have benefited from coming from JavaScript where there is also an abundance of choice, but as noted, in Rust choice of HTTP client implementation can have actual consequences on whether things work or not. This is the central lesson from this story, choices that are trivial and often completely inconsequential in other languages, have an outsized impact on Rust async programs. For someone who tries to "find" the right answer, it will take a long time to come to the actual correct answer: choice of HTTP client library depends on other factors.
Indeed, I think @cortopy's comments seem better served by the trust story.
@eminence @rylev the trust story is indeed very similar to mine. There are a lot of commonalities between the two and even the examples are similar. I must confess I only discovered this repo yesterday and hadn't read it, so that's my bad. Sorry.
If I had read it, I wouldn't have put so much emphasis on the compiler part, which, as you say, is a big part of what I wrote.
But as @nikomatsakis mentions, there is more to it. I mainly write APIs and web applications, and so I live, breath (and sometimes die!) in a completely asynchronous world. If one looks at https://www.arewewebyet.org/, every single library mentioned there is async. And so if Alan was to write a http server his Cargo.toml
will at some point end up with 10-20 dependencies, each with its own requirement for an async runtime.
This is out of scope for the initial story as suggested in this thread, but it also feels to me that just picking a http library is too simple of a task. As I mentioned, having tons of libraries for the same thing is bread and butter in other languages like Javascript. What feels particularly painful to me is the fact that choosing a HTTP client would rarely happen in isolation, and so Alan would also have to consider if he needs other async libraries. In an ideal world, he should also know which libraries he'll need in the future in order to make the right choice.
This last bit is what I think is not included in the trust story.
@cortopy I think the story we were sketching today -- see https://github.com/rust-lang/wg-async-foundations/pull/111.
I'd like to know if you think there is something not covered, because maybe you could write that story :)
Or extend an existing one
Another option: We could also consider a "sub-story". We haven't really talked about what that might mean, but it could be something like a new .md file (either in the status_quo
folder, or in a subfolder). It could contain a variation of the trust story (with a different focus, or additional details that were not part of the original story). Then we'd update the trust story with a new FAQ entry that says something like "Are there other variations of this story? Yes, see this sub-story"
Sure, why not :)
@nikomatsakis I'm not too sure if that story gathers my experience with Rust. I've not published a library yet, but I have consumed all the most popular ones. It seems that Alan and Barbara are "producers" (sorry, probably not a good word to describe people) of libraries.
My urge to write in this thread comes from the point of view of the "consumer". It's very likely that the library Alan and Barbara are writing has a limited scope. That in itself is a luxury, especially if they aim for one thing and one thing only. "Consumers" of libraries, on the other hand, will have a very long list of dependencies to work with: http client, http server, pub/sub routines, websockets, ORMs and database connections, caching in remote stores, etc.
In that regards, it surprised me the conversation about whether to use async or not. In the story I have in mind it's an absolute given. No one in their right mind would write a synchronous web server like it's the nineties
@eminence I'd be more than happy to write a sub-story. Maybe sub-stories could be linked to more than one (trust and http client)?. I think my story would begin with something like:
1. Someone visits https://www.arewewebyet.org/
2. As a result, s/he thinks Rust is great to write a REST API because async support seems to be ready in all those libraries
3. And then similarity with story x
4. But also something different
As a beginner in Rust, I would like to add to this thread with our real-life experience. We are currently facing issues which make me relate to this story (and are preventing us to switch to Rust):
We are trying to rewrite some of our services from Python to Rust and are looking to achieve the following:
What we did not succeed to do so far is:
FuturesUnordered
container would handle
that for us.For reference, the stackoverflow question where I was looking for help.
@cortopy
I don't totally understand it yet, but I'd love to see the story you're talking about! =) That said, i'm going to move your comment to a different issue, since it seems to be distinct from this particular issue. I'll leave follow-on comments there.
@rgreinho I'm going to break this story out into its own issue too! I'd love to hear more about it.
Brief summary
Alan is building a simple library for interacting with his favorite movie tracking app "numbersquard". Numbesquard exposes their data over a restful API. Alan, new to Rust, searches for an HTTP library and quickly gets sucked into long debates about async/sync IO, Surf vs reqwest vs curl, tokio vs async-standard, etc. Alan is so filled with doubt that he doesn't even write a line of code.
Optional details
This story is similar in many ways to #54, #49, and #45, but HTTP is so common and this particular situation so relevant to so many projects that I think it needs to be called out explicitly.