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

91–100 of 182 posts

Re: Why you might want async in your project

#91

Post by conradludgate »

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 not true for Rust. Await in rust builds a larger state machine from the former. It does no implicit thread or task spawns (unless the future you're awaiting does them explicitly).

Furthermore, async rust can be run single threaded

Re: Why you might want async in your project

#92

Post by quickthrower2 »

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.

Heuristics. Not going to read every article that negs me.

Re: Why you might want async in your project

#93

Post by biomcgary »

klabb3 wrote: post #87

I mean.. I appreciate that there are proponents and people trying to improve the state of async rust but to allude that everything is dandy is either dishonest or more likely a strong curse of knowledge bias. I’ve worked deeply in an async rust codebase at a FAANG company. The vast majority chooses a dialect of async Rust which involves arcs, mutices, boxing etc everywhere, not to mention the giant dep tree of crates…

Your position wrt green threads sounds like Graydon's (https://graydon2.dreamwidth.org/307291.html).

Re: Why you might want async in your project

#94

Post by bionhoward »

For the thing I’m working on, I have an infinite number of little tasks with potentially shared smaller subtasks.

How could I unleash all the processors on my computer on this workload and allow them to correctly avoid repeated calculation of results of shared subtasks?

For example, I’m using an outbox: im::OrdMap> and a situation might arise where one task could avoid repeating work on a subtask because that’s already in progress elsewhere by waiting for the key/value pair (so that process could do something else)

Would it be worth going to async for that?

How could a worker function know if some key in the outbox was already being calculated and it could work on something else?

How would you share an outbox like that across a bunch of rayon processes communicating with async?

(I’ll read smol docs and try to figure it out but this article made a lot of sense, thank you)

Re: Why you might want async in your project

#95

Post by za3faran »

cies wrote: post #84
fnord77 wrote: post #6

Earlier quoted context omitted.

the JVM is an underappreciated engineering marvel

> underappreciated widely used though. not sure if that count for appreciation, but i think it's one of the highest forms. it's not bad, not not great either. i miss proper sum types, and it really lament the fact that static things are nearly impossible to be mocked which prompts everyone to use DI for everything instead of static.

Java has sum types now with sealed interfaces and pattern matching. Records have detructoring out of the box, and I believe supporting it for general classes is in the works.

Re: Why you might want async in your project

#96

Post by Georgelemental »

klabb3 wrote: post #87

I mean.. I appreciate that there are proponents and people trying to improve the state of async rust but to allude that everything is dandy is either dishonest or more likely a strong curse of knowledge bias. I’ve worked deeply in an async rust codebase at a FAANG company. The vast majority chooses a dialect of async Rust which involves arcs, mutices, boxing etc everywhere, not to mention the giant dep tree of crates…

> Try to explain pin projection in simple terms.

Pin projection is the proccess of getting a pinned reference to a struct's field from a pinned reference to the whole struct. Simple concept, but the APIs currently on offer for it (`unsafe` code or macro hackery) are very subpar.

Re: Why you might want async in your project

#97

Post by PaulHoule »

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…

People miss that there is a quantitative aspect to these things as well as a qualitative aspect. That is, many programs allocate millions of pieces of memory a second and for a wide range of different purposes whereas there might be a limited number of other resources of an even more limited set of types. Any change in the code probably has some affect on memory allocation, but many changes won't have any effect on allocation of higher-level resources.

Thus the complexity of handling memory is greater than that of other resources and the consequences of getting it not 100% right are frequently worse.

Re: Why you might want async in your project

#98

Post by Dowwie »

Arnavion wrote: post #77

>Except, this isn’t a problem with Rust’s async, it’s a problem with tokio. tokio uses a 'static, threaded runtime that has its benefits but requires its futures to be Send and 'static. It's not a problem with tokio either. The author's point is specifically about the multi-threaded tokio runtime that allows tasks to be moved between worker threads, which is why it requires the tasks to be Send + 'static. Alternative…

Actix-web uses the single threaded Tokio runtime per physical core. This architecture is harder to design for than multi threaded async Tokio. Performance gains aren't worth the effort.

Re: Why you might want async in your project

#99

Post by ojkelly »

andy_xor_andrew wrote: post #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 bet…

> 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.

Yep this makes sense to me.

If your workload is CPU-bound then context switching to make progress on 10 tasks concurrently, is going to be slower than doing them sequentially.

But if it’s IO-bound you will spend most of your time waiting, which you could use to make progress on the other tasks.

Re: Why you might want async in your project

#100

Post by Gwypaas »

nextaccountic wrote: post #42
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…

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

In my experience async drop is a nice to have, not a must. Futures::block_on is good enough for the happy path in low stakes scenarios.

When dealing with async operations they tend to end up at a network boundary and thus the service enters distributed system land.

Now the async drop also has to handle the server crashing before the drop happens and at any time when it happens. Keeping that in mind trying to actually drop something becomes quite meaningless since you need to handle all other cases either way.

Post reply on HN