5 ms·

> In Erlang, it feels so elegant – you write your code in a linear way, no coloring of functions, no async/await, and it still works in a high performant, I wou

> In Erlang, it feels so elegant – you write your code in a linear way, no coloring of functions, no async/await, and it still works in a high performant, I would say, scheduled way with [inaudible]. My idea was “how can I have this experience in Rust?”. I think long term, we will view async, like we view the near/far/huge pointers - something that was required in the past for performance but is now obsolete. With Java’s project Loom, kernel improvements in efficiency of threading, and projects like this, for the vast majority of programmers, using async for concurrency will not be worth it.

laerus 4y ago
Algebraic effects can also potentially abstract all this away and make the runtime pluggable.
- beanjuiceII 4y ago
  has haskell made all this pluggable?
  - wtetzner 4y ago
    I don’t believe Haskell has support for algebraic effects. OCaml is getting them though.
    - the_duke 4y ago
      There are various Haskell effect libraries though. The big difference between effects and monads is that effects compose, while monads always require cumbersome mapping between domains.
    - thesz 4y ago
      "What is language feature in regular programming languages is a library in Haskell" I will continue repeat that. ;) I also wish other languages go the way Haskell goes. There is at least one algebraic effects library in hackage [1]. [1] https://hackage.haskell.org/package/effect-handlers https://hackage.haskell.org/package/effect-handlers
      - beanjuiceII 4y ago
        indeed thanks :)
      - wtetzner 4y ago
        Sure, but now your program needs to use this library everywhere, or implement Monad transformers etc. to interoperate with existing code.
        thesz 4y ago
        I can make my own library, or modify the library given above, or write a wrapper - I have more choice than "use this concrete syntax rule for that kind of things". Moreover, values with effects are first class values, I can pass them, extend them, combine them, in some rare cases inspect them, abstractly interpret them, and last, but not least, evaluate them. Most often than not, this is not the case when they are language feature.
Matthias247 4y ago
I tend to agree. While asnyc/await (and callbacks and promises before) solves an efficiency problem via compiler magic and language extensions, it's not obvious whether it's necessarily the best solution to the problem. The approach that Lunatic seems to take is building another runtime in userspace which takes care of scheduling while allowing methods to continue to look synchronous. A stackful coroutine framework would probably have allowed for the same without requiring WASM, so I'm kind of wondering whether that was considered too. But ideally we would just use kernel threads, and maybe look into fixing performance for the use-cases where they don't work that well at the moment (which are not a lot actually!). It's so much simpler to understand for most programmers, tools (like debuggers, profilers, etc) just work, and suffers much less from interoperability issues.
- astrange 4y ago
  I don't think you should add something complicated like async/await purely for efficiency reasons, but it's good for expressivity too. Coroutines are good; I think you'd end up inventing coroutines and CPS (aka calling a callback at the end of your function instead of returning) just because they're useful, but once you have them, they're unsafe and unstructured i.e. you can forget to call them when you meant to. Async/await does more than just concurrency; it explodes your function into a rather complicated state machine, but at the same time gives you structured coroutine control flow that prevents some kinds of bugs. That's why Swift added it before concurrency: https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md https://github.com/apple/swift-evolution/blob/main/proposals... Some languages have async/await sugar built around futures instead; this is a mistake and it's less efficient too.
  - Zababa 4y ago
    > Some languages have async/await sugar built around futures instead; this is a mistake and it's less efficient too. Could you elaborate on that?
    - astrange 4y ago
      - The syntax isn't as good. (this is more like a lot of minor annoyances than one big point, but you can see it discussed in the Swift pitches) - It's not visible to compiler optimizations so it can't optimize coroutines. - It's not visible to the OS scheduler, or a green thread scheduler. Any pattern where you start an async task and then later wait on it leads to priority inversions, because until your more important thread is waiting on it, the scheduler doesn't know it's going to, so it can't inherit the priority.
jayd16 4y ago
Loom looks cool but this comes up a lot but I think async/await covers cases Loom doesn't. When dealing with a situations where you do need to share a single OS thread (GPU commands) or want to use cooperative multitasking (very common in UI) you still probably want something like async/await. Maybe that just means you pass data between executors in those contexts but I think that will end up looking like async/await anyway.

laerus 4y ago

Algebraic effects can also potentially abstract all this away and make the runtime pluggable.

beanjuiceII 4y ago
has haskell made all this pluggable?
- wtetzner 4y ago
  I don’t believe Haskell has support for algebraic effects. OCaml is getting them though.
  - the_duke 4y ago
    There are various Haskell effect libraries though. The big difference between effects and monads is that effects compose, while monads always require cumbersome mapping between domains.
  - thesz 4y ago
    "What is language feature in regular programming languages is a library in Haskell" I will continue repeat that. ;) I also wish other languages go the way Haskell goes. There is at least one algebraic effects library in hackage [1]. [1] https://hackage.haskell.org/package/effect-handlers https://hackage.haskell.org/package/effect-handlers
    - beanjuiceII 4y ago
      indeed thanks :)
    - wtetzner 4y ago
      Sure, but now your program needs to use this library everywhere, or implement Monad transformers etc. to interoperate with existing code.
      - thesz 4y ago
        I can make my own library, or modify the library given above, or write a wrapper - I have more choice than "use this concrete syntax rule for that kind of things". Moreover, values with effects are first class values, I can pass them, extend them, combine them, in some rare cases inspect them, abstractly interpret them, and last, but not least, evaluate them. Most often than not, this is not the case when they are language feature.

Matthias247 4y ago

I tend to agree. While asnyc/await (and callbacks and promises before) solves an efficiency problem via compiler magic and language extensions, it's not obvious whether it's necessarily the best solution to the problem. The approach that Lunatic seems to take is building another runtime in userspace which takes care of scheduling while allowing methods to continue to look synchronous. A stackful coroutine framework would probably have allowed for the same without requiring WASM, so I'm kind of wondering whether that was considered too. But ideally we would just use kernel threads, and maybe look into fixing performance for the use-cases where they don't work that well at the moment (which are not a lot actually!). It's so much simpler to understand for most programmers, tools (like debuggers, profilers, etc) just work, and suffers much less from interoperability issues.

astrange 4y ago
I don't think you should add something complicated like async/await purely for efficiency reasons, but it's good for expressivity too. Coroutines are good; I think you'd end up inventing coroutines and CPS (aka calling a callback at the end of your function instead of returning) just because they're useful, but once you have them, they're unsafe and unstructured i.e. you can forget to call them when you meant to. Async/await does more than just concurrency; it explodes your function into a rather complicated state machine, but at the same time gives you structured coroutine control flow that prevents some kinds of bugs. That's why Swift added it before concurrency: https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md https://github.com/apple/swift-evolution/blob/main/proposals... Some languages have async/await sugar built around futures instead; this is a mistake and it's less efficient too.
- Zababa 4y ago
  > Some languages have async/await sugar built around futures instead; this is a mistake and it's less efficient too. Could you elaborate on that?
  - astrange 4y ago
    - The syntax isn't as good. (this is more like a lot of minor annoyances than one big point, but you can see it discussed in the Swift pitches) - It's not visible to compiler optimizations so it can't optimize coroutines. - It's not visible to the OS scheduler, or a green thread scheduler. Any pattern where you start an async task and then later wait on it leads to priority inversions, because until your more important thread is waiting on it, the scheduler doesn't know it's going to, so it can't inherit the priority.

jayd16 4y ago

Loom looks cool but this comes up a lot but I think async/await covers cases Loom doesn't. When dealing with a situations where you do need to share a single OS thread (GPU commands) or want to use cooperative multitasking (very common in UI) you still probably want something like async/await. Maybe that just means you pass data between executors in those contexts but I think that will end up looking like async/await anyway.