4 ms·

Functions are functions are functions. If I want to call a function synchronously, I just call it. If I want to parallelise, then I simply spawn the function in

by singularity2001 5y ago

Functions are functions are functions. If I want to call a function synchronously, I just call it. If I want to parallelise, then I simply spawn the function instead. I don't understand why this isn't the universally accepted correct answer. Why not put the async idea on the caller side alone, as suggested and as seen in go? fetch(url) // synchronous go fetch(url) // asynchronous if the compiled code of synchronous and async functions really has to look different for fundamental reasons, the compiler can still silently emit both versions (and gc unused variants) Someone please help me understand, or rid the world of this async-await mess.

dnautics 5y ago
This is what zig does, and I can attest it works fantastically. I use zig to dispatch C ABI FFI in erlang vm, which uses a unfriendly tail-call system to yield from cooperative C ABI code into it's preemptive scheduler. With zig async you can write traditional looping structures and yield back to the erlang vm inside your loop. Because zig has uncolored async you can call the same function using a different strategy (for example in a spawned os thread), and the yields will no-op without having to rewrite the function. > the compiler can still silently emit both versions I think that is zig's strategy under the hood (not 100% sure)
- AndyKelley 5y ago
  Zig only emits one version. Either: 1. The function does not have a suspend point, so it is emitted as a normal function, and it just gets called like a normal function at the async callsite. Await is a no-op. or... 2. It has a suspend point. It is emitted with the async calling convention, and any normal callsites to it also become suspend points.
  - dnautics 5y ago
    Thanks for clarifying!! I had my understanding inverted!
kortex 5y ago
`fetch (url) // synchronous` `go fetch(url) // asynchronous` This is not something you can readily abstract over. That depends on whether language is compiled vs interpreted, has a runtime or not, is scheduled or not, stack model, threading model, ownership model, and so on. `go myfunc()` implies something to dispatch, execute and reap that function and its metadata, and there's no one-size-fits-all solution. You can design a language that has this feature, but it's not without tradeoffs, and it's certainly not something you could just introduce to a language unless it already lends itself to it.
- gpderetta 5y ago
  FWIW, this is literally what Cilk bolts on top of C/C++. Except that for 'go' being spelled 'spawn'. Cilk is designed for parallelism more than for concurrency, but with a runtime augmented idle cpu detection, it would work perfectly for async io.

dnautics 5y ago

This is what zig does, and I can attest it works fantastically. I use zig to dispatch C ABI FFI in erlang vm, which uses a unfriendly tail-call system to yield from cooperative C ABI code into it's preemptive scheduler. With zig async you can write traditional looping structures and yield back to the erlang vm inside your loop. Because zig has uncolored async you can call the same function using a different strategy (for example in a spawned os thread), and the yields will no-op without having to rewrite the function. > the compiler can still silently emit both versions I think that is zig's strategy under the hood (not 100% sure)

AndyKelley 5y ago
Zig only emits one version. Either: 1. The function does not have a suspend point, so it is emitted as a normal function, and it just gets called like a normal function at the async callsite. Await is a no-op. or... 2. It has a suspend point. It is emitted with the async calling convention, and any normal callsites to it also become suspend points.
- dnautics 5y ago
  Thanks for clarifying!! I had my understanding inverted!

kortex 5y ago

`fetch (url) // synchronous` `go fetch(url) // asynchronous` This is not something you can readily abstract over. That depends on whether language is compiled vs interpreted, has a runtime or not, is scheduled or not, stack model, threading model, ownership model, and so on. `go myfunc()` implies something to dispatch, execute and reap that function and its metadata, and there's no one-size-fits-all solution. You can design a language that has this feature, but it's not without tradeoffs, and it's certainly not something you could just introduce to a language unless it already lends itself to it.

gpderetta 5y ago
FWIW, this is literally what Cilk bolts on top of C/C++. Except that for 'go' being spelled 'spawn'. Cilk is designed for parallelism more than for concurrency, but with a runtime augmented idle cpu detection, it would work perfectly for async io.