21–30 of 182 posts
async is not free. It will turn your code into a big state machine and each thing you await will likely create its own thread. There is simplicity in a avoiding that and having code that gets compiled to something that is straightforward and single threaded.
Awaits don’t create threads, at least not in any runtime I know of. There is usually a fixed number of threads at launch.
Earlier quoted context omitted.
I agree that memory management can't be solved locally. The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that. I disagree that this criticism applies to Rust. For 99% of the cases, the idiomatic combination of borrow checking, Box and Arc gets back to a unified, gl…
>The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that. Lol wut. The C++ resource management paradigm is RAII. If you write a library that doesn't use RAII, it's a bad library. Not a fault of the language.
Either you write code with good performance, which means that functions do take references and pointers sometimes, in which case you do have all of the usual lifetime issues. This is the proper way to use C++, and it's perfectly workable, but it's by no means automatic. That's the reality that my comment was referencing.
Or you live in a fantasy land where RAII solves everything, which leads to code where everything is copied all the time. I've lived in a codebase like this. It's the mindset that famously caused Chrome to allocate 25K individual strings for every key press: https://groups.google.com/a/chromium.org/g/chromium-dev/c/EU...
Now we have async/await and I'm always happy to see it.
I find async is so much fun in Python and meshes with the other things you can do with generators but that is because I have the reference collector cleaning up behind me. Looking back with like 30 years of hindsight it seems to me that Java’s greatest contribution to software reuse was efficient garbage collection; memory allocation is a global property of an application that can’t efficiently be localized as you mi…
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…
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.
async is not free. It will turn your code into a big state machine and each thing you await will likely create its own thread. There is simplicity in a avoiding that and having code that gets compiled to something that is straightforward and single threaded.
Awaits don’t create threads, at least not in any runtime I know of. There is usually a fixed number of threads at launch.
> 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.com/django/asgiref/blob/main/asgiref/sync.py
Ofc this is a python example. I have no idea how it works in different languages.
Earlier 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…
Don't static lifetimes just mean that leaking memory is considered 'safe' in rust?
"There is a common sentiment I’ve seen over and over in the Rust community that I think is ignorant at best and harmful at worst."
just refuses to read the rest? If you are actually trying to make a point to people that think differently than you, why antagonize them by telling them they don't know what they are talking about?
Earlier quoted context omitted.
>The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that. Lol wut. The C++ resource management paradigm is RAII. If you write a library that doesn't use RAII, it's a bad library. Not a fault of the language.
You have two choices. Either you write code with good performance, which means that functions do take references and pointers sometimes, in which case you do have all of the usual lifetime issues. This is the proper way to use C++, and it's perfectly workable, but it's by no means automatic. That's the reality that my comment was referencing. Or you live in a fantasy land where RAII solves everything, which leads to…
> strings being passed as char* (using c_str()) and then converted back to string
> Using a temporary set [...] only to call find on it to return true/false
> Not reserving space in a vector
c_str() isn't there for "good performance" to begin with; it's there for interfacing with C APIs. RAII or not, GC or not, you don't convert to/from C strings in C++ unless you have to.
The other stuff above have nothing to do with C++ or pointers, you'd get the same slowdowns in any language.
The language has come a long way since 2014. Notice what they said the solutions are:
> base::StringPiece [...]
a.k.a., C++17's std::string_view.
async is not free. It will turn your code into a big state machine and each thing you await will likely create its own thread. There is simplicity in a avoiding that and having code that gets compiled to something that is straightforward and single threaded.
Awaits don’t create threads, at least not in any runtime I know of. There is usually a fixed number of threads at launch.
async is not free. It will turn your code into a big state machine and each thing you await will likely create its own thread. There is simplicity in a avoiding that and having code that gets compiled to something that is straightforward and single threaded.
This is true of all abstractions; if you don't need them, then they'll make your program more complex and more painful to write and maintain. Exercising judgement about when to use or shirk an abstraction is a lot of what being a software engineer is about.
It adds complexity, but it's at the level where you don't have to think about it. If you're doing something advanced enough to where async is a leaky abstraction, you're probably doing something big enough to where you would want the advantages it offers.
If you're doing something simple, async is just a black box primitive that is pretty easy to use.