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

What async promised and what it delivered

causality.blog

Post reply on HN
Print view View original

251–260 of 317 posts

Re: What async promised and what it delivered

#251

Post by rerdavies »

anonymars wrote: post #92
pocksuppet wrote: post #81

Earlier quoted context omitted.

Inversion of thought pattern: Why is a thread such a waste that we can't have one per concurrent request? Make threads less wasteful instead. Go took things in this direction.

How do you suggest we just "make threads less wasteful"? I mean, I suppose we could move the scheduling and tracking out of kernel mode and into user mode... But then guess what we've just reinvented?

Colored functions. (Just thought I'd add that, because despite the rhetorical question, it took awhile for me to come up with the answer).

Re: What async promised and what it delivered

#252

Post by rerdavies »

default-kramer wrote: post #75
mbid wrote: post #39

How many systems are there that can't just spawn a thread for each task they have to work on concurrently? This has to be a system that is A) CPU or memory bound (since async doesn't make disk or network IO faster) and B) must work on ~tens of thousands of tasks concurrently, i.e. can't just queue up tasks and work on only a small number concurrently. The only meaningful example I can come up with are load balancers,…

I think it's another case of the whole industry being driven by the needs of the very small number of systems that need to handle >10k concurrent requests.

Also very useful for applications that have heavily animated graphical user interfaces, where you don't want I/O to interfere with UI animations on the UI thread. (e.g. ALL android apps. Or any UI framework that has a message pump (all of them?).

Re: What async promised and what it delivered

#253

Post by cmrdporcupine »

amluto wrote: post #211
cmrdporcupine wrote: post #136

Earlier quoted context omitted.

> Yes, and that's both memory and cpu usage that isn't needed No, it literally is not. The "memory" is just entries in a page table in the kernel and MMU. It shouldn't worry you at all. Nor is the CPU used by the kernel to manage those threads going to be necessarily less efficient than someone's handrolled async runtime. In fact given it gets more eyes... likely more. The sole argument I can see is just avoiding a h…

> > Yes, and that's both memory and cpu usage that isn't needed No, it literally is not. The "memory" is just entries in a page table in the kernel and MMU. It shouldn't worry you at all. Only if you never free one of those stacks. TLB flushes can be quite expensive.

Fair enough, though it's not like an async tasks runner doesn't have its own often relatively expensive book-keeping.

Re: What async promised and what it delivered

#254

Post by rerdavies »

pocksuppet wrote: post #83
jerf wrote: post #58

Earlier quoted context omitted.

Function coloring does not mean that functions take parameters and have return values. Result is not a color. You can call a function that returns a Result from any other function. Errors as return values do not color a function, they're just return values. Async functions are colored because they force a change in the rest of the call stack, not just the caller. If you have a function nested ten levels deep and it c…

You are stuck in a fixed pattern of thinking where async==color. Here's the meme origin: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... Here's the list of requirements: 1. Every function has a color. 2. The way you call a function depends on its color. 3. You can only call a red function from within another red function. 4. Red functions are more painful to call. 5. Some core library functions are re…

But we end up talking past each other if we're using different definitions of the word "colored".

Re: What async promised and what it delivered

#255

Post by apaprocki »

rafaelmn wrote: post #38
rstuart4133 wrote: post #33

Async is a Javascript hack that inexplicably got ported to other languages that didn't need it. The issue arose because Javascript didn't have threads, and processing events from the DOM is naturally event driven. To be fair, it's a rare person who can deal with the concurrency issues threads introduce, but the separate stacks threads provide a huge boon. They allow you to turn event driven code into sequential code.…

async/await came out of C# (well at least the JS version of it). There are a bunch of use cases for it outside of implementing concurrency in a single threaded runtime. Pretty much every GUI toolkit I've ever used was single threaded event loop/GUI updates. Green threads are a very controversial design choice that even JVM backed out of.

> async/await came out of C# (well at least the JS version of it).

Having been instrumental in accelerating bringing async/await to JS, it definitely was the case that it came from C# and we eagerly were awaiting its arrival in JS and worked with Igalia to focus on it and make it happen across browsers more quickly so people could actually depend on it.

Re: What async promised and what it delivered

#256

Post by rerdavies »

pocksuppet wrote: post #84
littlestymaar wrote: post #21

Earlier quoted context omitted.

I wish the “Function coloring” meme died. It made sense in the context of the original blog post (which was about callback hell, hence the “4. Red functions are more painful to call” section un the original blog post), but doesn't make sense in the context of async/await. There's literally nothing special with async, it's just an effect among many others. As soon as you start using function arguments instead of using…

async/await is just syntax-sugar callback hell

Sure. But syntax sugar that allows you to write functions whose content isn't indented 300 columns to the right whose flow of control is much easier to reason about.

Re: What async promised and what it delivered

#258

Post by jwarden »

dwattttt wrote: post #208
cma256 wrote: post #203

Earlier quoted context omitted.

That is an unfair characterization of Zig. The OP correctly points out: > Function signatures don’t change based on how they’re scheduled, and async/await become library functions rather than language keywords. The functions have the same calling conventions regardless of IO implementation. Functions return data and not promises, callbacks, or futures. Dependency injection is not function coloring.

These things _are_ function colouring, but they show function colouring isn't scary or hard. The original function colouring essay was much more about JavaScript's implementation than a general statement. If JavaScript had exposed a way for a synchronous function to call back into the runtime to wait for an async function to complete, it would still be just as coloured, but no one would be complaining about colour (d…

I think this is right. More specifically, the problem is JavaScript function colors mean Sync/Async, whereas Zig's mean Non-IO/IO. Using function colors for async is fundamentally unnecessary, whereas for I/O it is fundamentally necessary. You should be able to define a synchronous function that calls an asynchronous function. But it makes no sense to define a non-IO function that calls a function that does IO.

EDIT: with the exception of doing IO on a freshly allocated, in-memory buffer that doesn't escape the function call.

Re: What async promised and what it delivered

#259

Post by likeabbas »

mplanchard wrote: post #250
likeabbas wrote: post #246

Earlier quoted context omitted.

you’re talking to the core of the issue. In no other language did they try to satisfy the case of running on an embedded system vs general purpose computing. Async rust tried to, and came up with a solution that is not great for the majority of programmers writing rust. I wish to God that the rust library devs would admit to this fact - say that async rust should stay for embedded runtimes usecases, but we shouldn’t…

I write reams of async rust for a living, and completely disagree with this characterization. The concurrency primitives in the futures crate are able to elegantly model the large majority of places where concurrency is needed, and they are nicely compostable. More than once, we have wanted to improve the performance of some path and been able to lift the sequential model into a stream, evaluated concurrently with so…

I completely disagree. Having to make sure every little function is Send + Sync + lifetime even if it doesn't need it is fucking hell. writing concurrent code with plain kernel threads is so much easier to write and read.

If you just want to build a normal backend service, you can't escape async libraries. Wrapping the async functions with `block_on` is not ideal I'd rather just have access to standard sync primitives that don't need me to bring an entire async runtime into the system.

My ultimate point is - I would be happy if async stayed in its own world. But the fact is async has completely polluted the rust library landscape and you can't escape it. I'm working on a project that I hope to show rust users that async isn't needed for performant backend services, and that the code can be written much simpler without it.

Re: What async promised and what it delivered

#260

Post by jerf »

tcfhgj wrote: post #94
jerf wrote: post #58

Earlier quoted context omitted.

Function coloring does not mean that functions take parameters and have return values. Result is not a color. You can call a function that returns a Result from any other function. Errors as return values do not color a function, they're just return values. Async functions are colored because they force a change in the rest of the call stack, not just the caller. If you have a function nested ten levels deep and it c…

> If you are ten layers deep in a stack of synchronous functions and suddenly need to make an asynchronous call, the type signature of every individual function in the stack has to change. well, this isn't really true - at least for Rust: runtime.block_on(async{}); https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.htm...

See my other post about the point. If you "just" turn an async back into a sync call by completely blocking the async scheduler, yes, you've turned the async call back into a sync call, but you've done that by completely eliminating async-ness. That's not a general solution. That is exactly what everyone back when Node was promoting this style spent paragraph upon paragraph warning you not to do, because it just punts by eliminating the asyncness entirely. "Async is great when you completely discard it" is not a winning argument for async... which is OK, because it's not the argument anyone is making.
Post reply on HN