I wish something similar was officially worked on by the python core dev. Ouputting wasm and being able to interpret it is going yo be necessary for the language to stay relevant in 10 years. But it not a priority at all atm.
Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
Rust and WebAssembly in 2019
11–20 of 97 posts
Re: Rust and WebAssembly in 2019
#12Earlier quoted context omitted.
We could add support for and not need JS to load it. Once the host bindings are implemented that would be a good fit.
...but it couldn't interact with the DOM or do anything else without JavaScript.
Re: Rust and WebAssembly in 2019
#13Earlier quoted context omitted.
Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
You ‘just’ wasm-compile the whole interpreter. It could even be feasible with a cdn.
Re: Rust and WebAssembly in 2019
#14I am surprised that now it's possible to make a web app as fast as native app.
Is Visual Studio Code using WASM?
Re: Rust and WebAssembly in 2019
#15It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.
There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu.... But meanwhile, Webassembly is mainly just for C and Rust.
Re: Rust and WebAssembly in 2019
#16Figma uses WASM and some claim that it's even faster than natively implemented Sketch. I am surprised that now it's possible to make a web app as fast as native app. Is Visual Studio Code using WASM?
Re: Rust and WebAssembly in 2019
#17It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.
> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu... . But meanwhile, Webassembly is mainly just for C and Rust.
Re: Rust and WebAssembly in 2019
#18It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.
Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries, for the same reason those languages have c extensions rather than extensions in other large runtime languages today.
Re: Rust and WebAssembly in 2019
#19Earlier quoted context omitted.
We could add support for and not need JS to load it. Once the host bindings are implemented that would be a good fit.
Maybe! There’s not really much demand for such a thing. Web platform people don’t have the disdain for JS that many internet commenters do.
Re: Rust and WebAssembly in 2019
#20Earlier quoted context omitted.
Python is extremely dynamic and compiling it into wasm would likely be impossible or would generate extremely low-performing code.
You ‘just’ wasm-compile the whole interpreter. It could even be feasible with a cdn.