[deleted]
Why you might want async in your project
51–60 of 182 posts
Re: Why you might want async in your project
#52Recent and related:
Maybe Rust isn’t a good tool for massively concurrent, userspace software - https://news.ycombinator.com/item?id=37435515 - Sept 2023 (567 comments)
Re: Why you might want async in your project
#53FYI This is an interesting response by the maintainer* of smol to this recent discussion: https://news.ycombinator.com/item?id=37435515 * EDIT: corrected, thanks
Maintainer, not creator. Smol was originally created by stjepang, who has basically disappeared these days. EDIT: I originally incorrectly claimed that stjepang also created rather than maintained crossbeam, making the same msitake as I was correcting.
crossbeam was created by Aaron Turon (who has – inevitably – also left the Rust project): https://aturon.github.io/blog/2015/08/27/epoch/
Re: Why you might want async in your project
#54Lots of comments and arguments about async being big or complex, and it's really not, it's pulling in the runtimes that's big and complex, and I think Rust really failed by forcing libraries to explicitly choose a runtime. As a library developer you're then put in the position of not using async, or fragmenting yourself to just the subset of users or other libraries on your runtime.
Re: Why you might want async in your project
#55> I’ve written quite a few Rust projects where I expect it to only involve blocking primitives, only to find out that, actually, I’m starting to do a lot of things at once, guess I’d better use async.
In my experience (which, admittedly, is far less than the author, a developer of smol!) the answer to "I'm starting to do a lot of things at once" in Rust is usually to spin up a few worker threads and send messages between them to handle jobs, a la Ripgrep's beautiful implementation.
In a way, it seems like async Rust appears more often when you need to do io operations, and not so much when you just need to do work in parallel.
Of course, you surely can use async rust for work in parallel. But it's often easier to keep async out of it if you just need to split up some work across threads without bringing an entire async executor runtime into the mix.
I don't think async/await was poorly implemented in Rust - in fact, I think it avoids a lot of problems and pitfalls that could have happened. The complications arise because async/await is, kind of, ideologically antithetical to Rust's other goal of memory safety and single-writer. Rust really wants to have its cake (compile-time memory safety) and eat it too (async/await). And while you can criticize it, you have to admit they did a pretty good job given the circumstances.
Re: Why you might want async in your project
#56Earlier quoted context omitted.
Awaits don’t create threads, at least not in any runtime I know of. There is usually a fixed number of threads at launch.
FastAPI docs, case when you don't create an async route > When you declare a path operation function with normal def instead of async def, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server). https://fastapi.tiangolo.com/async/#path-operation-functions OP either meant this, or its variation, such as async_to_sync and sync_to_async. https://github.c…
NB: In Python >= 3.9 the idiomatic way to do this is to_thread(), not familiar with these ASGI functions but I would guess they're a polyfill and/or predate 3.9.
https://docs.python.org/3/library/asyncio-task.html#asyncio....
Re: Why you might want async in your project
#57Earlier quoted context omitted.
Python handles all kinds of stuff with garbage collection. The problem is that things like closing a socket are not just generic resources, a lot of the time nonmemory stuff has to be closed at a certain point in the program, for correctness, and you can't just let GC get to it whenever.
I don’t think this is true. Context managers call special magic “dunder” methods on the instance (I don’t remember the specific ones), and I’m pretty sure those don’t get called during regular garbage collection of those instances. It’s been a few years since I was regularly writing python, so I might be wrong, but I don’t believe that context manager friendly instances are the same as Rust’s Drop trait, and I don’t…
Python is a fun case of "all of the above" (or rather, a layering of styles once it turns out a previous one isn't workable).
Originally, they used pure reference counting GC, with finalizers used to clean up when freed. This was "fine", since RC is deterministic. Everything is freed when the last reference is deleted, nice and simple.
But reference counting can't detect reference cycles, so eventually they added a secondary tracing garbage collector to handle them. But tracing GC isn't deterministic anymore, so this also meant a shift to manual resource management.
That turned out to be embarrassing enough that context managers were eventually introduced to paper over it. But all four mechanisms still exist and "work" in the language today.
Re: Why you might want async in your project
#58> Why don’t people like async?
That's pretty simple. The primary goal of every software engineer is (or at least should be) ... no, not to learn a new cool technology, but to get the shit done. There are cases where async might be beneficial, but those cases are few and far in between. In all other cases a simple thread model, or even a single thread works just fine without incurring extra mental overhead. As professionals we need to think not only if some technology is fun, but how much it actually costs to our employer and about those who are going to maintain our "cool" code when we leave for better pastures. I know, I know, I sound like a grandpa (and I actually am).
Re: Why you might want async in your project
#59Earlier quoted context omitted.
Maintainer, not creator. Smol was originally created by stjepang, who has basically disappeared these days. EDIT: I originally incorrectly claimed that stjepang also created rather than maintained crossbeam, making the same msitake as I was correcting.
crossbeam was created by Aaron Turon (who has – inevitably – also left the Rust project): https://aturon.github.io/blog/2015/08/27/epoch/
Oops, shame on me!
Re: Why you might want async in your project
#60Earlier quoted context omitted.
The problem with garbage collection is that it doesn't work for other kinds of resources than memory, so basically every garbage collected runtime ends up with an awkward and kinda-broken version of RAII anyway (Closeable, defer, using/try-with-resources, context managers, etc). Static lifetimes are also a large part of the rest of Rust's safety features (like statically enforced thread-safety). A usable Rust-without…
> basically every garbage collected runtime ends up with an awkward and kinda-broken version of RAII anyway (Closeable, defer, using/try-with-resources, context managers, etc). RAII works only for the simplest case: when your cleanup takes no parameters, when the cleanup doesn't perform async operations, etc. Rust has RAII but it's unusable in async because the drop method isn't itself async (and thus may block the w…
There are workarounds. You could, for example, have a drop implementation spawn a task to do the I/O and exit.
Also, if your cleanup takes parameters, you can just store them in the struct.