4 ms·

What would be a good way to not have sync / async colors? Explicit yield / resume, like Lua? Full-on CPS?

by nine_k 2y ago

adastra22 2y ago
Go handles it quite nicely. It's not perfect, but it is nice. Every function is a coroutine. There is no such thing as a non-async fn in Go. But if you want explicit await-like concurrency, then you can explicitly wait on a message from a channel. Every time I bring this up there are people who jump in with excuses for why Rust can't do something similar. But these are either (1) historical accidents in the sense of implementing goroutines would've broken existing code [fair], or (2) excuses. Go's approach is much harder to get right, and much more pervasive in the impact on the language. But when it's done well, it's really smooth to use. I use Rust as my daily driver because I want the safety guarantees that Rust gives, and cargo is pretty nice. But every time I need to do something highly concurrent, I wish I was working in Go...
- gulbanana 2y ago
  There is a good reason why Rust can't do it the Go way - Go's always-async concurrency requires a fairly heavy runtime. Rust is designed to be able to support systems that have no runtime at all, or a specialised one. (https://embassy.dev/ https://embassy.dev/ is an example of a specialised async runtime for running async Rust on microcontrollers).
  - adastra22 2y ago
    Why wouldn't you be able to swap out the concurrency runtime for something else? Or not switch it off entirely when not needed (making the concurrency keyboards into syntax errors)?
    - zarzavat 2y ago
      You can, you can switch it off by declaring a normal non-async function. It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors. Go is a language that is primarily used for async programming, so the design of having everything async makes sense. Rust is a language that is primarily used for sync programming, async programming is catered for but it's not the focus of the language. So having everything be async doesn't make any sense at all.
      - Dylan16807 2y ago
        > It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors. Since any function can get indefinitely stuck in a system call, the main difference between "sync" and "async" isn't whether you can pause execution, it's who can pause execution. And the main downside to the more flexible option is that it requires extra overhead in how the stack gets allocated. But why should the flexible/inflexible choice be made on a per-function basis? I feel like I'm manually annotating which functions will inline, except worse because certain combinations won't compile. Instead, how about having the compiler figure it out on a per-call basis?
- kamov 2y ago
  Rust used to have a GC in the past, as well as green threads and a bigger runtime. All of this has been explicitly removed before Rust 1.0. The reasons are well documented in many pull requests and RFCs for the language. The way the async feature works in Rust is that the asynchronous function is just a syntax sugar that gets desugared into a state machine struct during compilation. The way this state machine works is similar to how one could achieve async in a language like C. It's unfair to dismiss everything as excuses given that the fundamental aim of the language is different. In Rust async functions are not really colored because again - the async function is just a syntax sugar for a struct you can create and use in a sync context. The colors analogy is only really applicable in a language like JavaScript, where there's no way to poll an async function in a sync context.
  - adastra22 2y ago
    Here's the thing though: Rust could have every function be an async state machine, automatically. And then the compiler optimizes away that code when it isn't needed. It would be a big pain to implement, but it's doable, and it would deliver a developer experience much closer to Go's. There isn't a technical reason for why Rust couldn't do this. FYI you can't poll an async result in a sync context in Rust, either.
    - dwattttt 2y ago
      > FYI you can't poll an async result in a sync context in Rust, either. Sure you can. Async runtimes in Rust are written in Rust, that's exactly what they do.
    - Ygg2 2y ago
      > There isn't a technical reason for why Rust couldn't do this. First, it would be a huge undertaking. That in itself is a huge time/resource burden. Second, it would add overhead to any non-async function call. Because async introduces branching on every function invocation, it would make the resulting assembly even harder to understand. This strongly goes against the zero overhead/ zero cost abstraction idea of Rust. By the same measure, Go could technically remove (almost) all GC, add some kind of borrowing mechanism and steal Rust's thunder.
elcritch 2y ago
Elixir/Erlang, Go, Java all do. Java is new to the game with “green threads”.

What would be a good way to not have sync / async colors? Explicit yield / resume, like Lua? Full-on CPS?

by nine_k 2y ago

What would be a good way to not have sync / async colors? Explicit yield / resume, like Lua? Full-on CPS?

Go handles it quite nicely. It's not perfect, but it is nice. Every function is a coroutine. There is no such thing as a non-async fn in Go. But if you want explicit await-like concurrency, then you can explicitly wait on a message from a channel. Every time I bring this up there are people who jump in with excuses for why Rust can't do something similar. But these are either (1) historical accidents in the sense of implementing goroutines would've broken existing code [fair], or (2) excuses. Go's approach is much harder to get right, and much more pervasive in the impact on the language. But when it's done well, it's really smooth to use. I use Rust as my daily driver because I want the safety guarantees that Rust gives, and cargo is pretty nice. But every time I need to do something highly concurrent, I wish I was working in Go...

gulbanana 2y ago
There is a good reason why Rust can't do it the Go way - Go's always-async concurrency requires a fairly heavy runtime. Rust is designed to be able to support systems that have no runtime at all, or a specialised one. (https://embassy.dev/ https://embassy.dev/ is an example of a specialised async runtime for running async Rust on microcontrollers).
- adastra22 2y ago
  Why wouldn't you be able to swap out the concurrency runtime for something else? Or not switch it off entirely when not needed (making the concurrency keyboards into syntax errors)?
  - zarzavat 2y ago
    You can, you can switch it off by declaring a normal non-async function. It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors. Go is a language that is primarily used for async programming, so the design of having everything async makes sense. Rust is a language that is primarily used for sync programming, async programming is catered for but it's not the focus of the language. So having everything be async doesn't make any sense at all.
    - Dylan16807 2y ago
      > It's almost as if there's two fundamentally different types of functions that people might want to declare, necessitating two function colors. Since any function can get indefinitely stuck in a system call, the main difference between "sync" and "async" isn't whether you can pause execution, it's who can pause execution. And the main downside to the more flexible option is that it requires extra overhead in how the stack gets allocated. But why should the flexible/inflexible choice be made on a per-function basis? I feel like I'm manually annotating which functions will inline, except worse because certain combinations won't compile. Instead, how about having the compiler figure it out on a per-call basis?
kamov 2y ago
Rust used to have a GC in the past, as well as green threads and a bigger runtime. All of this has been explicitly removed before Rust 1.0. The reasons are well documented in many pull requests and RFCs for the language. The way the async feature works in Rust is that the asynchronous function is just a syntax sugar that gets desugared into a state machine struct during compilation. The way this state machine works is similar to how one could achieve async in a language like C. It's unfair to dismiss everything as excuses given that the fundamental aim of the language is different. In Rust async functions are not really colored because again - the async function is just a syntax sugar for a struct you can create and use in a sync context. The colors analogy is only really applicable in a language like JavaScript, where there's no way to poll an async function in a sync context.
- adastra22 2y ago
  Here's the thing though: Rust could have every function be an async state machine, automatically. And then the compiler optimizes away that code when it isn't needed. It would be a big pain to implement, but it's doable, and it would deliver a developer experience much closer to Go's. There isn't a technical reason for why Rust couldn't do this. FYI you can't poll an async result in a sync context in Rust, either.
  - dwattttt 2y ago
    > FYI you can't poll an async result in a sync context in Rust, either. Sure you can. Async runtimes in Rust are written in Rust, that's exactly what they do.
  - Ygg2 2y ago
    > There isn't a technical reason for why Rust couldn't do this. First, it would be a huge undertaking. That in itself is a huge time/resource burden. Second, it would add overhead to any non-async function call. Because async introduces branching on every function invocation, it would make the resulting assembly even harder to understand. This strongly goes against the zero overhead/ zero cost abstraction idea of Rust. By the same measure, Go could technically remove (almost) all GC, add some kind of borrowing mechanism and steal Rust's thunder.

elcritch 2y ago

Elixir/Erlang, Go, Java all do. Java is new to the game with “green threads”.