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

11–20 of 182 posts

Re: Why you might want async in your project

#11

Post by Nullabillity »

PaulHoule wrote: post #2

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-lifetimes would end up looking a lot more like Haskell than Go.

Re: Why you might want async in your project

#13

Post by pphysch »

Nullabillity wrote: post #11
PaulHoule wrote: post #2

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 with garbage collection is that it doesn't work for other kinds of resources than memory

Why is that a "problem with GC"?

Abstracting away >90% of resource management (i.e. local memory) is a significant benefit.

It's like saying the "problem with timesharing OS" is that it doesn't address 100% of concurrency/parallelism needs.

Re: Why you might want async in your project

#14

Post by pbourke »

Nullabillity wrote: post #11
PaulHoule wrote: post #2

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…

I quite like context managers and try-with-resources style constructs. They make lifetimes explicit in the code in a fairly intuitive way. You can get yourself turned around if you deeply nest them, etc but there are usually ways to avoid those traps.

Re: Why you might want async in your project

#16

Post by meindnoch »

codeflo wrote: post #8
PaulHoule wrote: post #2

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…

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.

Re: Why you might want async in your project

#17

Post by ok123456 »

Nullabillity wrote: post #11
PaulHoule wrote: post #2

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…

Don't static lifetimes just mean that leaking memory is considered 'safe' in rust?

Re: Why you might want async in your project

#18

Post by api »

The author is a maintainer of smol, which I think is a far superior runtime to tokio for numerous reasons including structured concurrency, performance, size, and an ownership parameter that reduces the need for Arc all over the place by letting you scope on the runtime or task. The whole thing is just tighter and better thought out.

Yet tokio is the de facto standard and everything links against it. It’s really annoying. Rust should have either put a runtime in the standard library or made it a lot easier to be runtime neutral.

Re: Why you might want async in your project

#19

Post by maxbond »

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.

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.

Re: Why you might want async in your project

#20

Post by api »

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.
Post reply on HN