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. bvrmn+Xf[view] [source] 2024-01-19 23:27:11
>>andrew+Hd
> It’s a real game changer for python especially

Python is so slow you gain nothing with async. I have a plenty of cool stories how I've fixed crumbled products because they were async and all connection load instead of nginx/backend goes directly into db.

You rarely need long connections and if you choose async for python because it's fast then it's a wrong choice because it's not.

BTW asyncio is awful bloated implementation with huge overhead around task management.

◧◩◪◨
4. andrew+2i[view] [source] 2024-01-19 23:41:01
>>bvrmn+Xf
>> Python is so slow you gain nothing with async.

It’s not necessarily about speed, though this statement above is flat out wrong.

async in Python allows you to build different types of applications. For example you can attach a task to stdout of another process and read and process it.

◧◩◪◨⬒
5. bvrmn+Yj[view] [source] 2024-01-19 23:57:09
>>andrew+2i
> For example you can attach a task to stdout of another process and read and process it.

How max many processes you handled in this fashion? The catch is: if you need thousands than asyncio has too much overhead and you need manual epoll. If less threads are much easier to use and acceptable performance wise.

[go to top]