3 ms·

This seems like a great idea and I support the effort. It was not clear to me on first read though that what was being proposed is not an extension to current a

This seems like a great idea and I support the effort. It was not clear to me on first read though that what was being proposed is not an extension to current async rust (compiling code to a series of state machines), but a completely alternative design utilizing a context switching runtime like Erlang or Go. If I interpreted that wrong please correct me. Part of me wonders, considering that rust is a systems programming language, how difficult would it be to write a runtime like that in rust so that there is no need to use a second language?

whitten 2y ago
So your goal for the runtime would just be a different runtime for Rust ?
- dapperdrake 2y ago
  Unlikely. C and Rust have run-time environments. Just not as elaborate as the JVM for Java or a web browser for JS and WASM. It could only be about adding a second run-time environment to the same operating system process. That’s what the questions seems to be enquiring about. And it’s about instrumenting the Rust run-time environment with a REPL and human-friendly run-time data structures.
- mightyham 2y ago
  To be clear, in this comment, I am referring to async in the broadest sense. I am specifically NOT referring to the Rust compiler keyword and runtimes (like tokio) that work with rust future state machines. If I understand OP correctly his current proposal is to create a different runtime for rust. That runtime happens to be written in scheme using his own compiler. It is meant to make writing async rust applications easier by having simple rust interop. Given the authors implicit argument that an async runtime with a stack-based context switching model can provide better debugging. Is it possible to write something like that in rust? That may be better for some use cases, as it wouldn't result in a multi-language project.
dapperdrake 2y ago
Doesn’t seem like it. It’s about interactive instrumentation of the runtime. Think lua in Haskell adding slight reflection and a REPL. In another comment I referenced Chris Kohlhepp’s write up.

whitten 2y ago

So your goal for the runtime would just be a different runtime for Rust ?

dapperdrake 2y ago
Unlikely. C and Rust have run-time environments. Just not as elaborate as the JVM for Java or a web browser for JS and WASM. It could only be about adding a second run-time environment to the same operating system process. That’s what the questions seems to be enquiring about. And it’s about instrumenting the Rust run-time environment with a REPL and human-friendly run-time data structures.
mightyham 2y ago
To be clear, in this comment, I am referring to async in the broadest sense. I am specifically NOT referring to the Rust compiler keyword and runtimes (like tokio) that work with rust future state machines. If I understand OP correctly his current proposal is to create a different runtime for rust. That runtime happens to be written in scheme using his own compiler. It is meant to make writing async rust applications easier by having simple rust interop. Given the authors implicit argument that an async runtime with a stack-based context switching model can provide better debugging. Is it possible to write something like that in rust? That may be better for some use cases, as it wouldn't result in a multi-language project.

dapperdrake 2y ago

Doesn’t seem like it. It’s about interactive instrumentation of the runtime. Think lua in Haskell adding slight reflection and a REPL. In another comment I referenced Chris Kohlhepp’s write up.