I am not super familiar but let me give it a shot. My understanding is the main benefit is that you can have one ruby interpreter that can be used on any CPU a

I am not super familiar but let me give it a shot. My understanding is the main benefit is that you can have one ruby interpreter that can be used on any CPU architecture or operating system. This is especially interesting for web as you can implement the WASI interface and then run Ruby in the browser. This is especially cool for learning tools and IDEs. Another benefit is that by using a "safe" WASI backend you could run Ruby sandboxed which could be helpful for testing and dynamic analysis of untrusted code or even for IDE support for potentially dangerous code. (For example you can run the `rm -r /` function to see it's return type without actually letting it wipe the disk.) > that I could theoretically just end up with a single binary that contained everything in it? I don't think this changes anything here. You could do this just as easily with or without. > this is shipping a Ruby runtime inside of WASI or is it aiming to “compile” to “native”? My reading says that it is the former. Compiling the Ruby runtime to WASI. > Then finally, does this also theoretically do something big for Ruby’s performance metrics? It likely hurts performance as WASM will be slower than native.