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

131–140 of 182 posts

Re: Why you might want async in your project

#131

Post by sanderjd »

biomcgary wrote: post #93
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 ).

What an amazing article. I can't believe I missed it when he wrote it.

I followed Rust in the very early days and definitely came away with the sense in this article. I would have said (and may have said to some people) that Graydon is really great, but that the exciting things about Rust weren't the things he liked or cared about; basically the expressivity and zero cost abstractions sections of this article.

But reading the article he linked about first class modules, I think that seems pretty good, and I think he's definitely right about making borrowing "second class" without explicit lifetimes (or at least discouraging them more so than the language does today), and about existential types (I'm always surprised I don't see these more in library APIs).

I also had no idea he wanted built in bignums. In pre-1.0 (and pre-cargo) rust, I created a very incomplete library for that, and would have loved to have it built in instead. Also yeah, decimal literals would be excellent.

But I didn't find the async vs. green threads section convincing. The green thread implementation wasn't a great fit at the time it existed, and I haven't seen anything since then that convinces me there was some great solution available to make it work better. Async isn't great in rust, but it's a much better fit, and I think it can be used well. I have hopes that best practices developing over time and maybe language features or changes can push people in a more sane direction of usage (once it becomes more clear what that should be).

Re: Why you might want async in your project

#132

Post by sanderjd »

klabb3 wrote: post #103
biomcgary wrote: post #93

Earlier quoted context omitted.

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

Yeah, perhaps. But I am not part of that minuscule subset of people who have deep expertise in both compiler internals and runtime architecture to have well founded opinion on the design. There is FFI and stack issues that’d need some incredibly bright engineers to sort out. My argument is more along the lines of: modularity is the (only) way to reduce complexity. We already have modular runtimes in other languages (…

I do tend to agree with you, but just to note that both the approaches you listed for this are more recent than the decisions rust made on this. It's not "good approaches to modular runtimes were already rock solid, why didn't they consider them?". It's "people have done promising work on this in the last decade, maybe rust could figure out how to incorporate it in some way moving forward".

Re: Why you might want async in your project

#133

Post by losvedir »

insanitybit wrote: post #112
vc8f6vVV wrote: post #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 profess…

Show me how to cancel a network requests using only threads, with no access to the underlying socket APIs? Because that's trivial with `async`. That's not "fun", that's table stakes.

Total rust newb here, but does that need the full async story, or is it a limitation of an API somewhere? From the point of view of the code using the request's response could you use a channel with recv_timeout? Is the problem there that the thread with the socket connection is still going and there's no way to stop it?

Re: Why you might want async in your project

#134

Post by insanitybit »

losvedir wrote: post #133
insanitybit wrote: post #112

Earlier quoted context omitted.

Show me how to cancel a network requests using only threads, with no access to the underlying socket APIs? Because that's trivial with `async`. That's not "fun", that's table stakes.

Total rust newb here, but does that need the full async story, or is it a limitation of an API somewhere? From the point of view of the code using the request's response could you use a channel with recv_timeout? Is the problem there that the thread with the socket connection is still going and there's no way to stop it?

The ability to cancel an operation without talking to the operating system requires that your program has yield points. That yielding is what allows another part of the program to take control and say "OK, I'm done with you now, no need to finish".

Yes, the problem is that your thread would continue to perform work even if you stopped waiting on it.

Re: Why you might want async in your project

#135

Post by insanitybit »

imetatroll wrote: post #130
insanitybit wrote: post #110

Earlier quoted context omitted.

A Runtime generally refers to "things added to the program to make it work". That can mean libc, it can mean a GC, etc. > I don't understand the arguments on either side. In terms of what code looks like I far prefer being able to just declare green threads like golang does. Under the hood `async` is sugar over a function such that the function returns a `Future ` instead of a `T`. What is done with that future is up…

I don't really understand when you say that spawning async would be just like a green thread (goroutine). I thought they were fundamentally different.

They aren't different. They are the same. The only difference is that in Go the `yield` points are implicit (the compiler inserts them) whereas in Rust they are explicit (.await).

Otherwise they both schedule a task to be executed with the implicit runtime - in Rust that may be tokio or something else, in Go that would be the Go runtime.

Re: Why you might want async in your project

#136

Post by insanitybit »

bobbylarrybobby wrote: post #120
insanitybit wrote: post #109

Earlier quoted context omitted.

FWIW Arc implements From so you can do `let foo = blah().into()` and if `foo` is passed to something expecting Arc it'll be an Arc. This probably works for Arc > as well so you'd be able to do `.into().into()` but I'm not sure.

Iirc you can't chain .into() because the compiler can't be sure whether the first is meant to do the whole conversion and the second is the identity (impl From for T), or if the first does one step and the second the next or if the first is the identity and the second does the whole conversion. (In fact I think the existence of the first and third options alone is enough to preclude chained .into() from working due t…

You're right.

Re: Why you might want async in your project

#137

Post by insanitybit »

olalonde wrote: post #117
insanitybit wrote: post #110

Earlier quoted context omitted.

A Runtime generally refers to "things added to the program to make it work". That can mean libc, it can mean a GC, etc. > I don't understand the arguments on either side. In terms of what code looks like I far prefer being able to just declare green threads like golang does. Under the hood `async` is sugar over a function such that the function returns a `Future ` instead of a `T`. What is done with that future is up…

> That's fine - lots of Rust libraries that work the way you're suggesting will just assume a runtime exists. Is this a new development? Last time I checked, every library seemed to be tied to a specific runtime (usually tokio).

That's what I'm saying. When a library uses "spawn" it is generally assuming a runtime, typically tokio (although in my experience a lot of libraries are generic).

Re: Why you might want async in your project

#138

Post by vc8f6vVV »

insanitybit wrote: post #134
losvedir wrote: post #133

Earlier quoted context omitted.

Total rust newb here, but does that need the full async story, or is it a limitation of an API somewhere? From the point of view of the code using the request's response could you use a channel with recv_timeout? Is the problem there that the thread with the socket connection is still going and there's no way to stop it?

The ability to cancel an operation without talking to the operating system requires that your program has yield points. That yielding is what allows another part of the program to take control and say "OK, I'm done with you now, no need to finish". Yes, the problem is that your thread would continue to perform work even if you stopped waiting on it.

Maybe I don't understand the complexity, but in good old Ruby I can easily stop a thread if I don't need result anymore. No async needed and no yield points necessary. Doesn't it apply to Rust too?

Re: Why you might want async in your project

#139

Post by vc8f6vVV »

hgomersall wrote: post #122
vc8f6vVV wrote: post #118

Earlier quoted context omitted.

Nope, my answer boils down to: "I said I never had much use for one. Never said I didn't know how to use it." (c)

Honestly, your dismissal of its value sounds very much like you don't know how to use it. The whole argument can be turned around and the same said about threads, which are not "simple" as you suggest if you don't already know how to use them. You might as well say "simple async".

If you carefully read my message, I said there are cases where async is beneficial. Most of the time I don't think even threads are necessary. E.g. the most common application nowadays (arguably) is a web server. Of course those who write web server itself may use whatever technology that fits, but for us mortals who simply want to receive request, query DB and respond with data, even threads have a very limited usage. Why? Because web servers are highly parallel, you try to make your request processing parallel and you starve another request (DB is a limited resource, and most web apps don't require computational power). So a simple sync processing works just fine -- no headaches, no mental overhead and you can focus on the business logic, that's what your employer values the most. The exception is when your company name is Twitter or X, whatever (which the most of web apps are not). Other cases? Depends, but the same approach applies: we usually have a bottleneck somewhere else, so you are trying to be smart and starves that. And introducing a sophisticated approach where it's not necessary you shift the focus from the business logic (see above).

Re: Why you might want async in your project

#140

Post by [deleted] »

hgomersall wrote: post #122
vc8f6vVV wrote: post #118

Earlier quoted context omitted.

Nope, my answer boils down to: "I said I never had much use for one. Never said I didn't know how to use it." (c)

Honestly, your dismissal of its value sounds very much like you don't know how to use it. The whole argument can be turned around and the same said about threads, which are not "simple" as you suggest if you don't already know how to use them. You might as well say "simple async".

[deleted]
Post reply on HN