[leftyspook]

I think you make a pretty bad case for how embedding a Scheme interpreter is going to help with the pain points of async. Listing "stack traces full of tokio code" and then seemingly proposing to solve that by adding more glue to pollute the stack traces is especially weird.

[maplant]

Not an interpreter! A compiler :-)

Have you seen a stack trace originating from somewhere within tokio? Nearly all useful information is lost. My contention is that by isolating the functions that are required to be written in Rust and then doing orchestration, spawning, etc in Scheme the additional debug information at runtime will make the source of errors much more clear.

I could be wrong! But hey there’s other reasons too. Being able to debug Rust functions dynamically is pretty cool, as well as being able to start/stop them like daemons.

[giancarlostoro]

On the other hand, you might wind up with an impressive Scheme implementation.

[kanbankaren]

luajit gets you almost all of scheme features except macros. Speed of luajit is very close to native C.

[dapperdrake]

It seems like the intended application is live debugging. Lisp and Smalltalk have a rather nice history here. C, C++ boost and Rust tend more to be lands of contrasts.

Chris Kohlhepp has a great write up of embedding ECL in C++. The trick is to know about the C++ configure flag for building ECL. [0 with terminal screenshots, 1 on web archive without terminal screenshots]

Haskell people seem to like Lua. Just look at pandoc.

[0] https://isocpp.org/blog/2014/09/embedding-lisp

[1] https://web.archive.org/web/20200307212433/https://chriskohl...

[StilesCrisis]

I thought the same thing. It's a hard pivot from "async rust is hard" to "but if we add in Scheme it will be good!" With no real justification for it. I'm not a Scheme guy but I don't see the connection.