8 ms·

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async fun

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort.

sanxiyn 6y ago
Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
- haberman 6y ago
  I'm skimming your link trying to understand the design. It sounds like there is a global flag for whether the whole program is in evented or blocking mode? > during compile-time, it’s possible to inspect if the overall program is in evented mode or not, and properly designed code might decide to move to a threaded model when in blocking mode, for example.
  - sanxiyn 6y ago
    Yes, it's a top level application decision, not a library decision. In fact, this is exactly how allocation and unwinding is handled in Rust.
    - zozbot234 6y ago
      So, it's like the choice of a Tokio executor? That's a top-level default, too.
- lmm 6y ago
  Sounds like a horribly complex special case. I'd far rather just have higher-kinded types and be able to write sometimes-async code using normal polymorphism (like I do in Scala all the time).
knuthsat 6y ago
Yep, I was mind blown when I started using futures years ago with this coloring. But then I realized it’s all about types and monoids and applicatives and it started to get clear why I just can’t get the value out of a promise.
ernst_klim 6y ago
> One is they make your functions colored This is definitely a good thing. All computations should me "marked" as total or effectful with various possible effects (blocking, async, nondeterministic, possibly non-terminating etc etc). Reasoning about your program is hard when each computation is a blackbox possibly containing any side-effects which could cause unpredictable changes in the control flow and result in a completely incomprehensible way. Async/await thing is indeed least sound and ergonomic way of doing this. Monads with monad transformers are a bit better. Algebraic effects are the best in terms of composability, ergonomics and mental overhead, but not here yet (though OCaml may be soon become the first industrial-grade language incorporating them [1]) [1] https://www.youtube.com/watch?v=z8SI7WBtlcA https://www.youtube.com/watch?v=z8SI7WBtlcA
- akvadrako 6y ago
  > This is definitely a good thing. All computations should me "marked" as total or effectful with various possible effects (blocking, async, nondeterministic, possibly non-terminating etc etc). Marking functions for side-effects would be a good thing but it isn't what function coloring means in this context. An async function and a normal function are semantically the same, they just have different syntaxes and you can't easily call one from another. They can be both be either blocking or non-blocking, especially if they take other functions as arguments.
  - nostrademons 6y ago
    They're not really the same: you know that an async function may potentially suspend and have other code run before its completion, while a normal function (in the absence of threads and signals) is guaranteed to run atomically, at least as far as your process's memory space is concerned. You also know that the only points at which an async function may suspend are an 'await' statement, and so data invariants that don't cross await statements or other async function calls can be reasoned about as if you had purely sequential code. That's precisely the coloring that makes async useful. Without it you need to explicitly protect all shared data with mutexes or other synchronization primitives. 40+ years of threaded programming has shown that programmers cannot generally be trusted to get this right, and this in an area ripe with bugs.
varajelle 6y ago
> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks
- oblio 6y ago
  Based on this, the default value is 2MB: https://unix.stackexchange.com/questions/127602/default-stack-size-for-pthreads https://unix.stackexchange.com/questions/127602/default-stac... So that would mean a lot of memory for 1 million threads, 2TB of RAM. But you can change the default. With a 64k stack you'd use up ~68GB of RAM, which doesn't seem like a lot for 1 million threads and 1 million requests happening at the same time.
  - ibraheemdev 6y ago
    What "normal-sized Linux server" has 70GB of RAM?
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - oblio 6y ago
      One that wants to handle a million requests per second? Or would you want to do that with a Raspberry Pi? :-) > What "normal-sized Linux server" has 70GB of RAM? Also, why are you "quoting" what I did not say?
      - ComputerGuru 6y ago
        Air quotes.
      - ibraheemdev 6y ago
        I was quoting the parent comment by @akvadrako :)
deleted 6y ago
[deleted]
jedisct1 6y ago
> One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. Not in Zig: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
pvorb 6y ago
In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specialization of the concept that doesn't boil down to OS threads. I haven't used it yet, so I can only repeat the advertising copy, but nevertheless wanted to give some perspective from other ecosystems. [1]: https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main
- victor106 6y ago
  Loom is going to be a game changer. Hopefully they release it soon.
  - wbl 6y ago
    Didn't they start with green threads way back when?
    - lmm 6y ago
      Yes they did, and gave up because of serious problems with that approach. (Interestingly, so did Rust, more recently).
  - deleted 6y ago
    [deleted]
- johnnycerberus 6y ago
  Go and Zig already solved the problem. Java will follow soon with Loom, can't wait.
  - littlestymaar 6y ago
    Go “solved the problem” at the expense of being unable to interface with C libraries without a big performance penalty (and that's you'll have Rust in Chromium and not Go)
varajelle 6y ago
> One is they make your functions colored I don't get what's so bad about "colored" function. That color is just about the return type of the function. How do you return an error from a function that does not return a Result? You must call unwrap (panic) or change the colour of your function by changing the return type to Result and fix all the caller. Similarly, if you want to use a future from a non-async function, you either call `block_on(...)`, or you change the return type to a future by marking the function async. I don't think it is that bad. That's just the way explicitly typed programming languages work.
- vips7L 6y ago
  I think you've made me realize why I don't enjoy Rust. Every function is colored.

sanxiyn 6y ago

Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/

haberman 6y ago
I'm skimming your link trying to understand the design. It sounds like there is a global flag for whether the whole program is in evented or blocking mode? > during compile-time, it’s possible to inspect if the overall program is in evented mode or not, and properly designed code might decide to move to a threaded model when in blocking mode, for example.
- sanxiyn 6y ago
  Yes, it's a top level application decision, not a library decision. In fact, this is exactly how allocation and unwinding is handled in Rust.
  - zozbot234 6y ago
    So, it's like the choice of a Tokio executor? That's a top-level default, too.
lmm 6y ago
Sounds like a horribly complex special case. I'd far rather just have higher-kinded types and be able to write sometimes-async code using normal polymorphism (like I do in Scala all the time).

knuthsat 6y ago

Yep, I was mind blown when I started using futures years ago with this coloring. But then I realized it’s all about types and monoids and applicatives and it started to get clear why I just can’t get the value out of a promise.

ernst_klim 6y ago

> One is they make your functions colored This is definitely a good thing. All computations should me "marked" as total or effectful with various possible effects (blocking, async, nondeterministic, possibly non-terminating etc etc). Reasoning about your program is hard when each computation is a blackbox possibly containing any side-effects which could cause unpredictable changes in the control flow and result in a completely incomprehensible way. Async/await thing is indeed least sound and ergonomic way of doing this. Monads with monad transformers are a bit better. Algebraic effects are the best in terms of composability, ergonomics and mental overhead, but not here yet (though OCaml may be soon become the first industrial-grade language incorporating them [1]) [1] https://www.youtube.com/watch?v=z8SI7WBtlcA https://www.youtube.com/watch?v=z8SI7WBtlcA

akvadrako 6y ago
> This is definitely a good thing. All computations should me "marked" as total or effectful with various possible effects (blocking, async, nondeterministic, possibly non-terminating etc etc). Marking functions for side-effects would be a good thing but it isn't what function coloring means in this context. An async function and a normal function are semantically the same, they just have different syntaxes and you can't easily call one from another. They can be both be either blocking or non-blocking, especially if they take other functions as arguments.
- nostrademons 6y ago
  They're not really the same: you know that an async function may potentially suspend and have other code run before its completion, while a normal function (in the absence of threads and signals) is guaranteed to run atomically, at least as far as your process's memory space is concerned. You also know that the only points at which an async function may suspend are an 'await' statement, and so data invariants that don't cross await statements or other async function calls can be reasoned about as if you had purely sequential code. That's precisely the coloring that makes async useful. Without it you need to explicitly protect all shared data with mutexes or other synchronization primitives. 40+ years of threaded programming has shown that programmers cannot generally be trusted to get this right, and this in an area ripe with bugs.

varajelle 6y ago

> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks

oblio 6y ago
Based on this, the default value is 2MB: https://unix.stackexchange.com/questions/127602/default-stack-size-for-pthreads https://unix.stackexchange.com/questions/127602/default-stac... So that would mean a lot of memory for 1 million threads, 2TB of RAM. But you can change the default. With a 64k stack you'd use up ~68GB of RAM, which doesn't seem like a lot for 1 million threads and 1 million requests happening at the same time.
- ibraheemdev 6y ago
  What "normal-sized Linux server" has 70GB of RAM?
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - oblio 6y ago
    One that wants to handle a million requests per second? Or would you want to do that with a Raspberry Pi? :-) > What "normal-sized Linux server" has 70GB of RAM? Also, why are you "quoting" what I did not say?
    - ComputerGuru 6y ago
      Air quotes.
    - ibraheemdev 6y ago
      I was quoting the parent comment by @akvadrako :)

deleted 6y ago

[deleted]

jedisct1 6y ago

> One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. Not in Zig: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/

pvorb 6y ago

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specialization of the concept that doesn't boil down to OS threads. I haven't used it yet, so I can only repeat the advertising copy, but nevertheless wanted to give some perspective from other ecosystems. [1]: https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main

victor106 6y ago
Loom is going to be a game changer. Hopefully they release it soon.
- wbl 6y ago
  Didn't they start with green threads way back when?
  - lmm 6y ago
    Yes they did, and gave up because of serious problems with that approach. (Interestingly, so did Rust, more recently).
- deleted 6y ago
  [deleted]
johnnycerberus 6y ago
Go and Zig already solved the problem. Java will follow soon with Loom, can't wait.
- littlestymaar 6y ago
  Go “solved the problem” at the expense of being unable to interface with C libraries without a big performance penalty (and that's you'll have Rust in Chromium and not Go)

varajelle 6y ago

> One is they make your functions colored I don't get what's so bad about "colored" function. That color is just about the return type of the function. How do you return an error from a function that does not return a Result? You must call unwrap (panic) or change the colour of your function by changing the return type to Result and fix all the caller. Similarly, if you want to use a future from a non-async function, you either call `block_on(...)`, or you change the return type to a future by marking the function async. I don't think it is that bad. That's just the way explicitly typed programming languages work.

vips7L 6y ago
I think you've made me realize why I don't enjoy Rust. Every function is colored.