Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you might want async in your project

notgull.net

Post reply on HN
Print view View original

31–40 of 182 posts

Re: Why you might want async in your project

#31

Post by mplanchard »

eternityforest wrote: post #24
Nullabillity wrote: post #11

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…

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 think their cleanup code gets called during GC.

Re: Why you might want async in your project

#33

Post by winwang »

francasso wrote: post #27

Am I the only one that after reading opening sentences like "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?

I agree with your sentiment, but want to point out the irony of choosing ignorance after being insulted as ignorant.

Re: Why you might want async in your project

#34

Post by cma »

codeflo wrote: post #22
meindnoch wrote: post #16

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…

2014, isn't that pre-C++11 in Chromium?

Re: Why you might want async in your project

#35

Post by mplanchard »

a-dub wrote: post #32

do any of the async libraries for rust have good visualization tools for inspecting the implicit state machine that is constructed via this type of concurrency primitive?

Not sure if it’s exactly what you’re looking for, but tokio-console is pretty nice

Re: Why you might want async in your project

#36

Post by [deleted] »

tomwojcik wrote: post #25
api wrote: post #20

Earlier 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…

[deleted]

Re: Why you might want async in your project

#37

Post by francasso »

winwang wrote: post #33
francasso wrote: post #27

Am I the only one that after reading opening sentences like "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?

I agree with your sentiment, but want to point out the irony of choosing ignorance after being insulted as ignorant.

You are assuming that the article would actually increase my knowledge

Re: Why you might want async in your project

#38

Post by jeremyjh »

codeflo wrote: post #22
meindnoch wrote: post #16

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…

I agree that a lot of that happens in the real world. I disagree that RAII is not used in the real world. I worked on a very large codespace for ATM client software and we used it pervasively, and the only memory leak we had in my time there was in a third-party library which ... required the careful reading of documentation you mentioned.

Re: Why you might want async in your project

#39

Post by mplanchard »

tomwojcik wrote: post #25
api wrote: post #20

Earlier 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…

“run in a threadpool” isn’t the same as creating a thread though

Re: Why you might want async in your project

#40

Post by charcircuit »

api wrote: post #20
charcircuit wrote: post #12

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.

That is an implementation detail on where you put the code that is blocking or running concurrently from the main code. An executor could use a separate OS thread, or the application could itself schedule application levels threads onto a number of OS threads.

When writing a Future that will block for 5 seconds you will need to find somewhere to that you can put the code to block for 5 seconds. You don't technically need to even use an executor here.

Post reply on HN