5 ms·
It all comes down to "is it such a common scenario?". Honest answer is no. async is for specialized situations and shouldn't be the default.
by sanxiyn 6y ago
It all comes down to "is it such a common scenario?". Honest answer is no. async is for specialized situations and shouldn't be the default.
- steveklabnik 6y agoDepending on the kind of work you're doing, it may or may not be. If you're doing a lot of network IO, then yes, it is very common.
- ibraheemdev 6y agoasync is not the default. The standard library is 100% blocking, and Rust does not come with a runtime. However, async makes sense for a lot of people, which is why libraries like tokio and async-std are so popular.
- sanxiyn 6y agoasync does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust. Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.
- ksenzee 6y agoShouldn't an HTTP request library make async available? HTTP is the textbook example for async.
- sanxiyn 6y agoIt should, but it shouldn't be the default. Right now, reqwest is the default HTTP request library in Rust ecosystem, and async is mandatory for reqwest. This is a bad situation to be in.
- ibraheemdev 6y ago> async is mandatory for reqwest async is not mandatory for reqwest. It provides a blocking API as well. > reqwest is the default HTTP request library in Rust ecosystem There is no "default" libraries. There are popular HTTP clients other than reqwest that also provide blocking APIs such as isahc and ureq
- sanxiyn 6y agoreqwest provides a blocking API, but reqwest also always depends on Tokio. A blocking API doesn't help when I don't want Tokio in my dependency tree at all. I am using isahc, but that also doesn't help when (say) Rusoto AWS library pulls reqwest pulls Tokio pulls async.
- fastball 6y agoDoesn't sound like a problem with async, just sounds like you disagreeing about what good deps for your deps are.
- eropple 6y agoCan you explain exactly what that library using Tokio internally exposes to you that's a problem? Because, as written, this sounds like a religious argument.
- therein 6y agoIf you need to use (for the sake of the example) Rusoto, since it is based on tokio, you'll need to set up the Tokio executor or at least add a macro to your main for this to be done for you. I believe Rusoto actually would take care of this for you if you haven't done it yourself however friction arises when you were already using a different version of tokio and Rusoto is built against another. Basically, it isn't entirely opaque to you how it is handled.
- eropple 6y ago
- ibraheemdev 6y agoIf you think OS threads are "better" than async tasks, then use them. Other people want to use async, so they use it. Rust does not have a runtime and provides blocking APIs by default, but gives you the option to use async if you want to.
- Scarbutt 6y agoTrue, but everyday more and more libraries are getting tedious to use in blocking mode.
- josephg 6y agoIn rust you can block your thread on the completion of an async future. Let other people use async code if they want to, and you can write your code in a syncronous blocking kind of way.
- sidlls 6y agoIn fairness it's just the announcement of V1 of the library. There doesn't seem to me to be anyone promoting its use "everywhere". On the other hand, there has been from day one a sort of hype around Rust's safety features, and an eagerness to promote any new library or framework written in Rust as a savior of programming. This library, as you note, will be used inappropriately (i.e. in contexts where it's not really necessary or reasonable to do) and lead to the worst kinds of bugs--those that lurk in complicated, difficult to understand code, and that are generally worse than any memory-related security vulnerability.
- nemothekid 6y agoWeb servers are the quintessential product of async. It’s no surprise that for an industry dominated by web titans spend a lot of time writing web servers and have a huge interest in asynchronous processing. The importance of a sync was cemented way back in 1999 with the c10k problem with nginx vs Apache.
- sanxiyn 6y agoMost people are not writing the next nginx. They are writing web application servers behind nginx.
- austinshea 6y agoThis, merely, means that the web application code will hold back what Nginx is capable of serving.
- pvorb 6y agoIf you know that there will be 10k concurrent users in your application, go ahead and use async right from the start. But for the rest of us, simple, blocking code will do just fine and save us a few headaches.
- pvorb 6y agoAnd once you get to a limit, the alternative to rewriting everything in non-blocking code might be to put multiple instances of your blocking app on multiple VMs/k8s/whatever behind a load balancer.
- nchi3 6y agoOr, you just take the initial leap and write async from the start. For languages with decent abstractions such as async/await, it really isn't hard when you've done it for a while, and I'd make the same argument as one of the parent posters in that it's great "documentation". K8s is brings way more complexity and headache, so it's kind of funny that you suggest that before using async/await.
- deleted 6y ago[deleted]
- austinshea 6y agoParallelism is complicated, and it is valuable.
- jandrewrogers 6y agoRust is a systems programming language. Modern server software -- a primary use case for a systems language -- is heavily async by default for a long list of compelling architectural reasons. Providing first-class language tooling to support that seems eminently sensible since this is how people will want to use the language. When you are writing high-performance server code, async is the common scenario.