5 ms·

> I do fully understand people who can't get their heads around threads and prefer async This is a bizarre remark Async/await isn't "for when you can't get y

by tomck 11mo ago

> I do fully understand people who can't get their heads around threads and prefer async This is a bizarre remark Async/await isn't "for when you can't get your head around threads", it's a completely orthogonal concept Case in point: javascript has async/await, but everything is singlethreaded, there is no parallelism Async/await is basically just coroutines/generators underneath. Phrasing async as 'for people who can't get their heads around threads' makes it sound like you're just insecure that you never learned how async works yet, and instead of just sitting down + learning it you would rather compensate Async is probably a more complex model than threads/fibers for expressing concurrency. It's fine to say that, it's fine to not have learned it if that works for you, but it's silly to put one above the other as if understanding threads makes async/await irrelevant > The stdlib isn't too bad but last time I checked a lot of crates.io is filled with async functions for stuff that doesn't actually block Can you provide an example? I haven't found that to be the case last time I used rust, but I don't use rust a great deal anymore

vjerancrnjak 11mo ago
It's more about how the code ends up evolving. Async-await in JS is sometimes used to swallow exceptions. It's very often used to do 1 thing at a time when N things could be done instead. It serializes the execution a lot when it could be concurrent. if (await is_something_true()) { // here is_something_true() can be false } And above, the most common mistake. Similar side-effects happen in other languages that have async-await sugar. It smells as bad as the Zig file interface with intermediate buffers reading/writing to OS buffers until everything is a buffer 10 steps below. It's fun for small programs but you really have to be very strict to not have it go wrong (performance, correctness).
- tomck 11mo ago
  I think you replied to the wrong person. That being said, I don't understand your `is_something_true` example. > It's very often used to do 1 thing at a time when N things could be done instead That's true, but I don't think e.g. fibres fare any better here. I would say that expressing that type of parallel execution is much more convenient with async/await and Promise.all() or whatever alternative, compared to e.g. raw promises or fibres.
  - vjerancrnjak 11mo ago
    I replied directly to you. There are valid arguments as to why async-await sucks, even after you're deeply familiar with how it works. Even though it's just generators/coroutines beneath, async-await pollutes the code completely if you're not strict about its usage. `is_something_true` is very simple, if condition is true, and then inside the block, if you were to check again it can be false, something that can't happen in synchronous code, yet now, with async-await, it's very easy to get yourself into situations like these, even though the code seems to yell at you that you're in the true branch. the solution is adding a lock, but with such ease to write async-await, it's rarely caught
    - tomck 11mo ago
      > I replied directly to you My comment was responding only to the person who equated threads and async. My comment only said that async and threading are completely orthogonal, even though they are often conflated > `is_something_true` is very simple, if condition is true, and then inside the block, if you were to check again it can be false, something that can't happen in synchronous code It can happen in synchronous code, but even if it couldn't - why is async/await the problem here? what is your alternative to async/await to express concurrency? Here are the ways it can happen: 1. it can happen with fibers, coroutines, threads, callbacks, promises, any other expression of concurrency (parallel or not!). I don't understand why async/await specifically is to blame here. 2. Even without concurrency, you can mutate state to make the value of is_something_true() change. 3. is_something_true might be a blocking call to some OS resource, file, etc - e.g. the classic `if (file_exists(f)) open(f)` bug. I am neutral on async/await, but your example isn't a very good argument against it Seemingly nobody ever has any good arguments against it > async-await pollutes the code completely if you're not strict about its usage This is a good thing, if a function is async then it does something that won't complete after the function call. I don't understand this argument about 'coloured functions' polluting code. if a function at the bottom of your callstack needs to do something and wait on it, then you need to wait on it for all functions above. If the alternative is just 'spin up an OS thread' or 'spin up a fiber' so that the function at the bottom of the callstack can block - that's exactly the same as before, you're just lying to yourself about your code. Guess what - you can achieve the same thing by putting 'await' before every function call Perhaps you have convinced me that async/await is great after all!
ksec 11mo ago
>Case in point: javascript has async/await, but everything is singlethreaded, there is no parallelism, Async/await is basically just coroutines/generators underneath. May be I just wish Zig dont call it async and use a different name.
dang 11mo ago
> This is a bizarre remark > makes it sound like you're just insecure > instead of just sitting down + learning it you would rather compensate Can you please edit out swipes like these from your HN posts? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Your comment would be fine without those bits.

by tomck 11mo ago

vjerancrnjak 11mo ago

It's more about how the code ends up evolving. Async-await in JS is sometimes used to swallow exceptions. It's very often used to do 1 thing at a time when N things could be done instead. It serializes the execution a lot when it could be concurrent. if (await is_something_true()) { // here is_something_true() can be false } And above, the most common mistake. Similar side-effects happen in other languages that have async-await sugar. It smells as bad as the Zig file interface with intermediate buffers reading/writing to OS buffers until everything is a buffer 10 steps below. It's fun for small programs but you really have to be very strict to not have it go wrong (performance, correctness).

tomck 11mo ago
I think you replied to the wrong person. That being said, I don't understand your `is_something_true` example. > It's very often used to do 1 thing at a time when N things could be done instead That's true, but I don't think e.g. fibres fare any better here. I would say that expressing that type of parallel execution is much more convenient with async/await and Promise.all() or whatever alternative, compared to e.g. raw promises or fibres.
- vjerancrnjak 11mo ago
  I replied directly to you. There are valid arguments as to why async-await sucks, even after you're deeply familiar with how it works. Even though it's just generators/coroutines beneath, async-await pollutes the code completely if you're not strict about its usage. `is_something_true` is very simple, if condition is true, and then inside the block, if you were to check again it can be false, something that can't happen in synchronous code, yet now, with async-await, it's very easy to get yourself into situations like these, even though the code seems to yell at you that you're in the true branch. the solution is adding a lock, but with such ease to write async-await, it's rarely caught
  - tomck 11mo ago
    > I replied directly to you My comment was responding only to the person who equated threads and async. My comment only said that async and threading are completely orthogonal, even though they are often conflated > `is_something_true` is very simple, if condition is true, and then inside the block, if you were to check again it can be false, something that can't happen in synchronous code It can happen in synchronous code, but even if it couldn't - why is async/await the problem here? what is your alternative to async/await to express concurrency? Here are the ways it can happen: 1. it can happen with fibers, coroutines, threads, callbacks, promises, any other expression of concurrency (parallel or not!). I don't understand why async/await specifically is to blame here. 2. Even without concurrency, you can mutate state to make the value of is_something_true() change. 3. is_something_true might be a blocking call to some OS resource, file, etc - e.g. the classic `if (file_exists(f)) open(f)` bug. I am neutral on async/await, but your example isn't a very good argument against it Seemingly nobody ever has any good arguments against it > async-await pollutes the code completely if you're not strict about its usage This is a good thing, if a function is async then it does something that won't complete after the function call. I don't understand this argument about 'coloured functions' polluting code. if a function at the bottom of your callstack needs to do something and wait on it, then you need to wait on it for all functions above. If the alternative is just 'spin up an OS thread' or 'spin up a fiber' so that the function at the bottom of the callstack can block - that's exactly the same as before, you're just lying to yourself about your code. Guess what - you can achieve the same thing by putting 'await' before every function call Perhaps you have convinced me that async/await is great after all!

ksec 11mo ago

>Case in point: javascript has async/await, but everything is singlethreaded, there is no parallelism, Async/await is basically just coroutines/generators underneath. May be I just wish Zig dont call it async and use a different name.

dang 11mo ago

> This is a bizarre remark > makes it sound like you're just insecure > instead of just sitting down + learning it you would rather compensate Can you please edit out swipes like these from your HN posts? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Your comment would be fine without those bits.