zlacker

[return to "The bane of my existence: Supporting both async and sync code in Rust"]
1. gavinh+tc[view] [source] 2024-01-19 23:06:42
>>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.

◧◩
2. andrew+Hd[view] [source] 2024-01-19 23:13:54
>>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.

◧◩◪
3. Twenty+6f[view] [source] 2024-01-19 23:21:56
>>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?

◧◩◪◨
4. andrew+Zf[view] [source] 2024-01-19 23:27:22
>>Twenty+6f
Threads are far more heavy than async.

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

◧◩◪◨⬒
5. Twenty+Eh[view] [source] 2024-01-19 23:38:41
>>andrew+Zf
> Threads are far more heavy than async

This sounds like an issue with the implementation of threads and scheduling in common operating systems, and I don't see how replicating all that functionality inside of each sufficiently large programming language is remotely taken seriously.

But also, you didn't respond to what I even said. You claimed that async is 'beautiful and natural'. I disagreed. You...fell back to a performance claim that's uncontroversially true, but irrelevant to what I said.

◧◩◪◨⬒⬓
6. andrew+HW[view] [source] 2024-01-20 07:32:14
>>Twenty+Eh
There's no concurrency issues with async programming.

No race conditions, no inter thread coordination, no concerns about all the weird shit that happens when doing multi threading.

◧◩◪◨⬒⬓⬔
7. dannym+Ma1[view] [source] 2024-01-20 10:54:20
>>andrew+HW
One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have. So you will still have all the concurrency issues with async in that case.

Only if you limited async to only one thread on one core (why would you do that?) you could avoid that.

◧◩◪◨⬒⬓⬔⧯
8. andrew+ih1[view] [source] 2024-01-20 11:57:02
>>dannym+Ma1
>> One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have

Errrr..... no it's not. Your statement is flat out wrong. async is single threaded.

You're not really understanding async.

async is single threaded. If you want to maximise your cores then run multiple instances of a single threaded process using systemd or something, or use your application to launch multiple async threads.

You can, in python and probably in Rust, run an executor, which essentially is running a synchronous process in a thread to make some bit of synchronous work compatible with async, but that's not really ideal and it's certainly not the purpose of async.

◧◩◪◨⬒⬓⬔⧯▣
9. Twenty+BF1[view] [source] 2024-01-20 15:07:29
>>andrew+ih1
`async` is neither multi-threaded nor single-threaded by default. It all depends on the underlying runtime.

Rust's Tokio runtime, for example, is multi-threaded by default and makes progress on several tasks at the same time by using multiple threads.

[go to top]