8 ms·

When the ecosystem is synchronous like the Rust ecosystem, you are basically going to rewrite everything. All your network code, all your client libraries. Asy

by fooyc 10y ago

When the ecosystem is synchronous like the Rust ecosystem, you are basically going to rewrite everything. All your network code, all your client libraries. Async code can not use synchronous code because this would block it, and prevent it from returning to the event loop. This is a tedious task, and you end up with less tested, less complete code (at least during the first few years) compared to the sync libraries provided by vendors and std libs. Event Nodejs still doesn't have ported the world to async yet, and still uses a thread pool under the hood for a number of things (e.g. name resolving), which defeats the promises of async I/O. Synchronous code can not use asyn code either because, well, in order to get anything from async code you have to be async yourself. Async code is also more difficult to reason about compared to classical blocking code. The idea behind async code is to avoid the cost of context switches and the memory usage of OS threads. But they are not the only way to avoid these costs. Go, Erlang, Haskell do a great job at this, without forcing the world into async. And since this guy is way better than me at writing, I'm going to leave this url here : http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

pcwalton 10y ago
I really dislike the "what color is your function" article, because it pushes the idea that Go's userspace M:N threading is somehow different from everything just being synchronous and using threads. It isn't. Go just doesn't have async I/O, with a particular idiosyncratic implementation of threads.
- fooyc 10y ago
  It IS different. In async code every single line of code must be async (or be very fast and i/o free), else you block everything. In Go, you can decide that a call frame and all its descendants will live their own life in a separate thread of execution. But inside of that call frame, the code is just usual, synchronous code. It doesn't event need to know that it's a goroutine. It is just executing concurrently to other code, at a very low cost to the computer and to the programmer. Go doesn't have async i/o by choice, it just doesn't need to. Though I'm pretty just there must be a libevent or libuv binding somewhere.
  - tomjakubowski 10y ago
    pcwalton said Golang's userspace threading model with Golang's I/O is equivalent to using "normal" threads with synchronous I/O, not that it's different from using threads and "async" I/O.
  - stymaar 10y ago
    >> somehow different from everything just being synchronous and using threads > It IS different. In async code every single line of code must be async I think you misread the gp. He was not saying that Go code is not different from async code (what you understood), he said it's not different from synchronous code using threads.
    - fooyc 10y ago
      You are right, I misread it. I agree that there is no visible difference in the code, and that's exactly what I like. What's different, however, is how Go routines have much less overhead than OS threads.
      - pcwalton 10y ago
        It's not as much as you think, and goroutines also have significant overheads that OS threads don't. Most of the time, when people talk about goroutine overhead, they're referring to the small stacks, which are actually a property of GC--there are language implementations that are 1:1 that also have small stacks, such as SML/NJ.
steveklabnik 10y ago
Thanks! Much more substantial. We're definitely aware of all of this. Tokio is made by two Rust core team members and the person who wrote the most widely used async io tool; it's virtually all but provided by Rust itself. And the ecosystem is aware of this too; the other people who were working on AIO have backed tokio as well, and the Rust community in general is interested in not having this split. > Synchronous code can not use asyn code either because, well, in order to get anything from async code you have to be async yourself. This is solvable through a threadpool, which tokio provides. In other words, it lets you make a blue function red. > But they are not the only way to avoid these costs These do not avoid all costs. For example, they pay the overhead of green threads, which means that you can't interoperate with C code at zero cost. That's a price a language like Rust cannot pay.
- fooyc 10y ago
  > the Rust community in general is interested in not having this split How will you avoid having two variants of each and every lib ? E.g. redis-rs, sync, and redis-tokio, async ? > you can't interoperate with C code at zero cost Go can't because it has different a memory layout and calling conventions. Other than that, what are you thinking about exactly ?
  - steveklabnik 10y ago
    > How will you avoid having two variants of each and every lib ? E.g. redis-rs, sync, and redis-tokio, async ? If the async version is easy to use, why would you use an explicitly synchronous one? > Other than that, what are you thinking about exactly ? Green threads. To call into C, you need to switch stacks. This is (one of the big reasons) why we removed green threads from Rust.
    - fooyc 10y ago
      > If the async version is easy to use Having a sync interface would make it easy to use in sync code, yes. I feel that we are far from zero cost abstractions now, though. > switch stacks Is it because the stacks in green threads is smaller than what C would expect ? An interesting approach taken by Go here is to avoid calling C as much as possible. They don't call the libc for system calls, for instance. This is also what allows them to switch the execution to an other goroutine just before the syscall.
akiselev 10y ago
> The idea behind async code is to avoid the cost of context switches and the memory usage of OS threads. But they are not the only way to avoid these costs. Go, Erlang, Haskell do a great job at this, without forcing the world into async. You're not avoiding the cost, you're just moving the runtime and language/code complexity costs around. Each of the techniques used by Go, Erlang, and Haskell to implement coroutines have trade-offs and there is two that Rust simply cannot make and still fulfill its goals: lose low overhead bidirectional C interop and add a language runtime. Performant coroutine implementations (AFAIK) all require moving the stack pointer around which makes it very expensive to have code call FFI functions. C makes certain assumptions about the stack and invariants need to be upheld, especially when the foreign library takes a function pointer from the host language. These features require a runtime which is out of the question for a low level language.
oconnor663 10y ago
> Async code can not use synchronous code because this would block it, and prevent it from returning to the event loop. This sounds like a JS-specific issue, where you're not allowed to spawn new threads for historical/implementation reasons? Even in Python and Ruby, where the GILs prevent threads from really running in parallel most of the time, you can still use them to unblock an event loop around a long-running function.
- fooyc 10y ago
  Using threads to make sync code async defeats the advantages of doing async code in the first place. You are writing async code to avoid threads. If you bring threads in your async code, you get the worse of both worlds: Convoluted code, and thread issues (pool exhaustion and/or thread overhead).
  - oconnor663 10y ago
    Of course. Switching back and forth between async and threads can be a bad sign. I didn't mean to say that you should do it all the time, rather just to put some context around this: > You can only call a red function from within another red function. That's really really true in JS. There's no way to call an async function from a sync function, if you need to return its result. You are Capital-S-Screwed if you need to do that. But it's going to far to apply that absolute rule to other languages. When you have threads, it's pretty easy to mix sync and async code. It can be a bad idea, just like having a codebase that's half exceptions and half error returns is usually a bad idea, but you're certainly allowed to do it when it makes sense.
  - grzm 10y ago
    Threads and async are orthogonal. Threads allow you to do work in parallel. Async allows you to increase CPU utilization in a single process/thread. writing async code to avoid threads Async can be used in single-process systems. It can make sense to use async techniques to maximize work being done on each process/thread. Working with threads and using async methods can both be complex if you don't have good abstractions for doing so. They can be used together to great effect if you have the right tools.

by fooyc 10y ago

pcwalton 10y ago

I really dislike the "what color is your function" article, because it pushes the idea that Go's userspace M:N threading is somehow different from everything just being synchronous and using threads. It isn't. Go just doesn't have async I/O, with a particular idiosyncratic implementation of threads.

fooyc 10y ago
It IS different. In async code every single line of code must be async (or be very fast and i/o free), else you block everything. In Go, you can decide that a call frame and all its descendants will live their own life in a separate thread of execution. But inside of that call frame, the code is just usual, synchronous code. It doesn't event need to know that it's a goroutine. It is just executing concurrently to other code, at a very low cost to the computer and to the programmer. Go doesn't have async i/o by choice, it just doesn't need to. Though I'm pretty just there must be a libevent or libuv binding somewhere.
- tomjakubowski 10y ago
  pcwalton said Golang's userspace threading model with Golang's I/O is equivalent to using "normal" threads with synchronous I/O, not that it's different from using threads and "async" I/O.
- stymaar 10y ago
  >> somehow different from everything just being synchronous and using threads > It IS different. In async code every single line of code must be async I think you misread the gp. He was not saying that Go code is not different from async code (what you understood), he said it's not different from synchronous code using threads.
  - fooyc 10y ago
    You are right, I misread it. I agree that there is no visible difference in the code, and that's exactly what I like. What's different, however, is how Go routines have much less overhead than OS threads.
    - pcwalton 10y ago
      It's not as much as you think, and goroutines also have significant overheads that OS threads don't. Most of the time, when people talk about goroutine overhead, they're referring to the small stacks, which are actually a property of GC--there are language implementations that are 1:1 that also have small stacks, such as SML/NJ.

steveklabnik 10y ago

Thanks! Much more substantial. We're definitely aware of all of this. Tokio is made by two Rust core team members and the person who wrote the most widely used async io tool; it's virtually all but provided by Rust itself. And the ecosystem is aware of this too; the other people who were working on AIO have backed tokio as well, and the Rust community in general is interested in not having this split. > Synchronous code can not use asyn code either because, well, in order to get anything from async code you have to be async yourself. This is solvable through a threadpool, which tokio provides. In other words, it lets you make a blue function red. > But they are not the only way to avoid these costs These do not avoid all costs. For example, they pay the overhead of green threads, which means that you can't interoperate with C code at zero cost. That's a price a language like Rust cannot pay.

fooyc 10y ago
> the Rust community in general is interested in not having this split How will you avoid having two variants of each and every lib ? E.g. redis-rs, sync, and redis-tokio, async ? > you can't interoperate with C code at zero cost Go can't because it has different a memory layout and calling conventions. Other than that, what are you thinking about exactly ?
- steveklabnik 10y ago
  > How will you avoid having two variants of each and every lib ? E.g. redis-rs, sync, and redis-tokio, async ? If the async version is easy to use, why would you use an explicitly synchronous one? > Other than that, what are you thinking about exactly ? Green threads. To call into C, you need to switch stacks. This is (one of the big reasons) why we removed green threads from Rust.
  - fooyc 10y ago
    > If the async version is easy to use Having a sync interface would make it easy to use in sync code, yes. I feel that we are far from zero cost abstractions now, though. > switch stacks Is it because the stacks in green threads is smaller than what C would expect ? An interesting approach taken by Go here is to avoid calling C as much as possible. They don't call the libc for system calls, for instance. This is also what allows them to switch the execution to an other goroutine just before the syscall.

akiselev 10y ago

> The idea behind async code is to avoid the cost of context switches and the memory usage of OS threads. But they are not the only way to avoid these costs. Go, Erlang, Haskell do a great job at this, without forcing the world into async. You're not avoiding the cost, you're just moving the runtime and language/code complexity costs around. Each of the techniques used by Go, Erlang, and Haskell to implement coroutines have trade-offs and there is two that Rust simply cannot make and still fulfill its goals: lose low overhead bidirectional C interop and add a language runtime. Performant coroutine implementations (AFAIK) all require moving the stack pointer around which makes it very expensive to have code call FFI functions. C makes certain assumptions about the stack and invariants need to be upheld, especially when the foreign library takes a function pointer from the host language. These features require a runtime which is out of the question for a low level language.

oconnor663 10y ago

> Async code can not use synchronous code because this would block it, and prevent it from returning to the event loop. This sounds like a JS-specific issue, where you're not allowed to spawn new threads for historical/implementation reasons? Even in Python and Ruby, where the GILs prevent threads from really running in parallel most of the time, you can still use them to unblock an event loop around a long-running function.

fooyc 10y ago
Using threads to make sync code async defeats the advantages of doing async code in the first place. You are writing async code to avoid threads. If you bring threads in your async code, you get the worse of both worlds: Convoluted code, and thread issues (pool exhaustion and/or thread overhead).
- oconnor663 10y ago
  Of course. Switching back and forth between async and threads can be a bad sign. I didn't mean to say that you should do it all the time, rather just to put some context around this: > You can only call a red function from within another red function. That's really really true in JS. There's no way to call an async function from a sync function, if you need to return its result. You are Capital-S-Screwed if you need to do that. But it's going to far to apply that absolute rule to other languages. When you have threads, it's pretty easy to mix sync and async code. It can be a bad idea, just like having a codebase that's half exceptions and half error returns is usually a bad idea, but you're certainly allowed to do it when it makes sense.
- grzm 10y ago
  Threads and async are orthogonal. Threads allow you to do work in parallel. Async allows you to increase CPU utilization in a single process/thread. writing async code to avoid threads Async can be used in single-process systems. It can make sense to use async techniques to maximize work being done on each process/thread. Working with threads and using async methods can both be complex if you don't have good abstractions for doing so. They can be used together to great effect if you have the right tools.