Fork me on GitHub
#sci
<
2022-09-14
>
telekid21:09:18

Fun thought, sci could be used similarly to lua, e.g. 1. compile sci -> js -> webasm 2. execute webasm in rust using something like https://github.com/wasmerio/wasmer Has anyone experimented with something like this? I like the idea of being able to closely marry rust’s performance and memory safety with clojure’s agility, with a nice container (webasm) separating the two.

didibus00:09:06

I'm no expert on Wasm, but this doesn't seem to bring any benefits to the mix? Running compiled Wasm on a rust implemented Wasm runtime doesn't really bring any of the rust performance or memory safety benefit to Clojure from what I understand.

didibus00:09:47

Wasm's benefits is going the other way around. From Rust you can compile code that then runs in the browser, therefore benefiting from Rusts no-gc but safe memory model and better performance.

didibus00:09:13

Wasm also could be a nice write ounce run anywhere runtime, just like the JVM is, except the JVM can't run in the browser and Wasm can, so Wasm could have even more reach, but going that direction as far as I know then it doesn't matter what the Wasm runtime is implemented in. It's like how the fact JVM is implemented in C doesn't mean Clojure can leverage C like performance.

borkdude21:09:15

@jake142 I haven't tried, but this sounds like a nice experiment

telekid21:09:35

might give it a try next month

borkdude21:09:31

let me know if you have any questions or ideas you want input on

telekid21:09:52

Will do! 🙏

telekid21:09:39

I’ve fantasized about building a scriptable live music environment around Clojure, but the realtime-ish requirements of audio have always made this tricky. This sounds like a nice way to give expressiveness to a composer with Clojure, but allow the audio engine to remain in a more appropriate language.

didibus00:09:06

Have you seen Overtone? It does exactly that, uses SuperCollider (C++ based) as the audio engine

borkdude10:09:57

@jake142 I've thought more about this and the idea fascinates me, but I wouldn't know where to start if I wanted to play with this myself. Would you use quickjs or so?

borkdude11:09:57

Perhaps compile QuickJS + SCI as built-in dependency to WASM and then use this WASM from a Rust binary?

telekid15:09:17

> Perhaps compile QuickJS + SCI as built-in dependency to WASM and then use this WASM from a Rust binary? I should caveat this by saying I don’t know much about the individual components yet, it would take me a fair amount of research to understand what approach is feasible. But my gut says yeah, that approach makes sense to me. I also wonder if it’s possible to cut out quickjs altogether. Basically, write a bit of sci that opens up a repl connection, compile that down to wasm, and then run it in a rust binary. Then, just interact with the repl. Would that work, or am I crazy? This is a little hard for me to reason about, but my hunch is that you don’t actually need a full JS runtime since sci itself can do the interpreting…

borkdude15:09:11

SCI is an interpreter that runs in either a JVM (or natively compiled with graalvm) or in a JS runtime

borkdude15:09:51

SCI itself isn't a platform independent runtime, like Clojure, it depends on the host platform

telekid15:09:14

ah of course, makes sense

telekid15:09:49

hm, then I wonder if SCI would bring any advantage over just CLJS -> QuickJS -> WASM -> Rust.

borkdude15:09:22

well "just CLJS" won't let you evaluate anything

telekid15:09:55

Okay I’ll need to bang my head against this for a bit to build a better intuition. In particular, I think I need a better understanding of how CLJS’s repl works. (Oh, does CLJS repl evaluation work by passing forms through the closure compiler? I hadn’t really thought about that before, but I guess that would make sense.)

borkdude15:09:40

Yes, but with SCI it's pretty easy to build a REPL

telekid15:09:21

:thumbsup: that was the missing bit for me.

telekid15:09:57

Let me know if you do end up playing with this at all, I’ll do the same. There might be something here.