
Rust async/await hits stable tomorrow - cdbattags
https://github.com/rust-lang/rust/blob/master/RELEASES.md
======
dang
I appreciate the enthusiasm, but please wait until a thing actually happens
before posting it here.

Otherwise we end up having to penalize the actual thing as a dupe, or have
repetitive split discussion.

~~~
cdbattags
Sincerely sorry! Didn't know this was the policy.

------
vbezhenar
I don't understand the obsession with async code. I can understand it with
JavaScript: browser environment was crippled and node copied that instead of
making proper threading available. But for most environments it's not a
problem. Just use thread pool and enjoy sane sequential programming model.
Yes, it might not work for Google scale. But it should work for the vast
majority of projects and if you really need to think about scaling, you should
think about scalable architecture to be able to scale to multiple machines.

It's like every programming language and framework today suddenly decides to
introduce those async primitives and I've yet to find a single use-case for it
in my projects.

~~~
jchw
> It's like every programming language and framework today suddenly decides to
> introduce those async primitives and I've yet to find a single use-case for
> it in my projects.

Consider that maybe this is because your projects are not the intended targets
of async programming.

Async is super not new. Fibers and CSP and etc. are not new. A lot of the
benefit of better concurrency is exactly for stuff that scales horizontally,
but just because you can scale to hundreds of boxes does not mean you want
each box to be bottlenecked on how many connections it can handle. For servers
you absolutely want to be able to use your nodes to their fullest. Demand for
this is almost certainly driving programming languages.

10 boxes handling 10000 connections > 100 boxes handling 1000 connections
(edit: _each_ )

~~~
vbezhenar
You can use async network calls to handle multiple number of connections (in
library code) yet use thread pool to write business logic (application code).

I'm not suggesting to just use blocking I/O API. Non-blocking API like
select/epoll/etc is very useful and should be utilized whenever possible. I'm
about those language features.

~~~
jchw
Why is this approach nicer than event loops w/ async/await or goroutines? I
think forcing humans to manually deal with continuations is not humane :)

------
riquito
Can we avoid posting "1 day earlier" news? We're just going to dilute the
discussions

------
wsgeek
Async is great... all those times a thread is waiting for even fractions of a
second can now be easily put to use... using the same thread if needed (a big
win for single threaded Python for example).

~~~
gdxhyrd
That already happens with any competent scheduler, no?

