3 ms·

In my experience people complain about it because they are coming from a blocking first mindset. They're trying to shoehorn async calls into an inherently synch

by scuff3d 5mo ago

In my experience people complain about it because they are coming from a blocking first mindset. They're trying to shoehorn async calls into an inherently synchronous structure. A while back I just started leaning in. I write a lot of Python at work, and anytime I have to use a library that's relies on asyncio, I just write the entire damn app as an asynchronous one. Makes function coloring a non-issue. If I'm in a situation where the two have to coexist, the async runtime gets its own thread and communication back and forth is handled at specific boundaries.

otabdeveloper4 5mo ago
> Makes function coloring a non-issue. Yes, having to rewrite literally all of your code because you need to use an async function somewhere is an issue. An even bigger issue is that now you have two (incompatible!) versions of literally every library dependency.
- scuff3d 5mo ago
  I'm usually writing applications, not libraries, so it's a non-issue for me. I was talking about when writing from scratch.
coldtea 5mo ago
>In my experience people complain about it because they are coming from a blocking first mindset. They're trying to shoehorn async calls into an inherently synchronous structure. There's no "inherently synchronous structure", at least not in Javascript. The nature is synchronous, asynchronous is an illusion built on top of it. Which is why you can easily block an "asynchronous" program: while (true) {} on any async function will do. JavaScript execution is synchronous on a single call stack. That's why they added Workers which is different to async. Rust's Tokio and co are also blocking. You need threads to get something that's not an inherently synchronous with merely a facade or cooperative asychronicity.
- scuff3d 5mo ago
  You're blending concepts. All parallelism is asynchronous, but not all "asynchrony" is parallel. I have to use Python as as an example since I don't have much experience with JavaScript, but when you're using asyncio, that's single threaded non-blocking IO (asynchronous). Each use of "await" yields execution back to the event loop, and it can can schedule some other task to run. Tasks can run asynchronously, but no in parallel. When you use the multiprocess library you are actually creating new threads that run in parallel (I'm ignoring the threading library because it just muddies the water). That's also asynchronous execution. I don't know the semantics as well in JavaScript, but I'm sure the principle is the same. At certain points you can yield to the runtime and it will schedule other pending tasks to execute while the current one is pending. My point was that mistake I see people make (in Python) is they think of their program in blocking terms by default. So they get this frustrating coloring problem because they are trying to shoehorn in non-blocking calls. If instead you design the application from the start with asyncio in mind, it makes things much simpler.
  - coldtea 5mo ago
    >All parallelism is asynchronous, but not all "asynchrony" is parallel. Sure, but my comment was not about parallelism compared to asynchronous, but about the idea that Javascript is above the "blocking first mindset". Javascript depends on a blocking (single-threaded, run-to-completion) backend. The asynchronicity on top of this blocking layer is an abstraction based on cooperative yielding. Whereas e.g. Erlang's asynchronicity is part of the runtime model itself.
    - scuff3d 5mo ago
      Yeah but nothing I said disputed that. Practically all languages have concurrency built on top of an inherently single threaded execution environment. The two standouts are Erlang based languages and Go. My point, coming from Python, was that whenever I can I write the entire application as an asyncio app, which cuts down on the function coloring problem. That doesn't mean you don't have to be careful, it's super easy to accidentally block the event loop.
troupo 5mo ago
> They're trying to shoehorn async calls into an inherently synchronous structure. You can make any async system synchronous. It's much harder to mske a sync sydtem asynchronous. (Misquoting from something Erlang-related). There are many cases when I don't care if a function call is asynchronous. I'm happy to wait for the result. Yet too many systems tell me I can't, for no good reason.

by scuff3d 5mo ago

otabdeveloper4 5mo ago

> Makes function coloring a non-issue. Yes, having to rewrite literally all of your code because you need to use an async function somewhere is an issue. An even bigger issue is that now you have two (incompatible!) versions of literally every library dependency.

scuff3d 5mo ago
I'm usually writing applications, not libraries, so it's a non-issue for me. I was talking about when writing from scratch.

coldtea 5mo ago

>In my experience people complain about it because they are coming from a blocking first mindset. They're trying to shoehorn async calls into an inherently synchronous structure. There's no "inherently synchronous structure", at least not in Javascript. The nature is synchronous, asynchronous is an illusion built on top of it. Which is why you can easily block an "asynchronous" program: while (true) {} on any async function will do. JavaScript execution is synchronous on a single call stack. That's why they added Workers which is different to async. Rust's Tokio and co are also blocking. You need threads to get something that's not an inherently synchronous with merely a facade or cooperative asychronicity.

scuff3d 5mo ago
You're blending concepts. All parallelism is asynchronous, but not all "asynchrony" is parallel. I have to use Python as as an example since I don't have much experience with JavaScript, but when you're using asyncio, that's single threaded non-blocking IO (asynchronous). Each use of "await" yields execution back to the event loop, and it can can schedule some other task to run. Tasks can run asynchronously, but no in parallel. When you use the multiprocess library you are actually creating new threads that run in parallel (I'm ignoring the threading library because it just muddies the water). That's also asynchronous execution. I don't know the semantics as well in JavaScript, but I'm sure the principle is the same. At certain points you can yield to the runtime and it will schedule other pending tasks to execute while the current one is pending. My point was that mistake I see people make (in Python) is they think of their program in blocking terms by default. So they get this frustrating coloring problem because they are trying to shoehorn in non-blocking calls. If instead you design the application from the start with asyncio in mind, it makes things much simpler.
- coldtea 5mo ago
  >All parallelism is asynchronous, but not all "asynchrony" is parallel. Sure, but my comment was not about parallelism compared to asynchronous, but about the idea that Javascript is above the "blocking first mindset". Javascript depends on a blocking (single-threaded, run-to-completion) backend. The asynchronicity on top of this blocking layer is an abstraction based on cooperative yielding. Whereas e.g. Erlang's asynchronicity is part of the runtime model itself.
  - scuff3d 5mo ago
    Yeah but nothing I said disputed that. Practically all languages have concurrency built on top of an inherently single threaded execution environment. The two standouts are Erlang based languages and Go. My point, coming from Python, was that whenever I can I write the entire application as an asyncio app, which cuts down on the function coloring problem. That doesn't mean you don't have to be careful, it's super easy to accidentally block the event loop.

troupo 5mo ago

> They're trying to shoehorn async calls into an inherently synchronous structure. You can make any async system synchronous. It's much harder to mske a sync sydtem asynchronous. (Misquoting from something Erlang-related). There are many cases when I don't care if a function call is asynchronous. I'm happy to wait for the result. Yet too many systems tell me I can't, for no good reason.