3 ms·

I’m only vaguely familiar with WASI so forgive me if this is a set of dumb questions. Would this mean that instead of complicated Ruby deployments where I need

by mhoad 5y ago

I’m only vaguely familiar with WASI so forgive me if this is a set of dumb questions. Would this mean that instead of complicated Ruby deployments where I need an app server, a Ruby runtime and a bunch of other magic that I could theoretically just end up with a single binary that contained everything in it? Secondly, this is shipping a Ruby runtime inside of WASI or is it aiming to “compile” to “native”? Not exactly sure what those terms mean in a WASI context hence the quotes. Then finally, does this also theoretically do something big for Ruby’s performance metrics? Edit: thanks for the insight in the comments below

kevincox 5y ago
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.
rgrmrts 5y ago
As I understand it, this proposal brings cruby to WASM. As in the code for Ruby itself, the vm, compiler, etc. WASI is just an interface to the host system and is not specifically related to native compiling

by mhoad 5y ago

kevincox 5y ago

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.

rgrmrts 5y ago

As I understand it, this proposal brings cruby to WASM. As in the code for Ruby itself, the vm, compiler, etc. WASI is just an interface to the host system and is not specifically related to native compiling