zlacker

>>lukast+(OP)
I hope that someday, we can have a Rust-like language without async.

Bonus points if it has the ability for users to define static analysis a la borrow checking.

>>gavinh+tc
Async programming is beautiful. It’s the easiest and most natural way to do multiple things at the same time in single threaded code.

Async makes things possible that are hard or impossible to do with synch programming.

It’s a real game changer for python especially. Cant comment on rust, hopefully its implementation is smooth.

>>andrew+Hd
Is it really though? All I personally care for when it comes to "doing multiple things at the same time" is frankly Rust's scoped threads API: Create N threads, have them perform some computations, then join them at the end of the scope.

How is this not more natural than creating various state machines and passing around all sorts of weird highly abstract Future-objects?

>>Twenty+6f
Threads are far more heavy than async.

Async code maximizes the potential of the thread it’s running in.

>>andrew+Zf
How many connections to Spotify did you want to keep open simultaneously?

>>Animat+xv
Not related to Spotify, but managing http2 connections is much easier with async code than with sync, and http3 will be much the same. You can of course probably spawn a thread that handles these connections and use channels, but it's not going to be particularly pleasant to work with.

With the Spotify API before I have wanted to do concurrent API calls. One api call gives you a list of song IDs in a playlist, then you want to get all the song info for each ID. HTTP2 multiplexing would be much nicer than spawning 100 different http1 connections