run-wasm
run-wasm copied to clipboard
language support (discussion)
Hi, Very nice project. Excellent work, indeed. This comment is just for discussion and to ask about the scope of the project.
Do you plan to add more language support? I believe you do.
I have done some research about running different languages in the browser. I found a few patterns:
- Compiling/transpiling to JavaScript, [e.g. TypeScript, CoffeeScript, LiveScript, ReScript, Reason, OCaml, Python (brython), Go (GopherJS), Ruby (Opal), Perl (Perlito5), PHP (Uniter), F# (Fable) ...etc]
- Re-implementing language runtime environment in JavaScript [e.g. Lua (fengari-web), Scheme (Biwascheme)]
- Running WASM [e.g. Python (Pyodide), AssemblyScript, F# (Bolero), SQL (SQL.js)]
So, do you plan to only support running wasm (group 3) or do you plan to extend to other groups?
P.S. I see you already plan to support AssemblyScript. I suggest you have a look at Bolero which also uses wasm to run F#.
P.P.S. You may see demos for most of these running in LiveCodes starter templates: https://dev.livecodes.io/?screen=new
Are you aware of any other projects that allows running user code in the browser? Rust? C#? C++? Java?
Thank you, and great work 👍
I would love to see support for TypeScript and Rust personally
Yeah we're explicitly trying to support wasm based languages, so option #3.
We think long term if we use wasm based languages across the stack we'll be able to focus and improve the experience overall across the language executions.
Tbh we don't know a ton internally about wasm _yet. _
We just know we want to build and improve on language execution in the browser via wasm long term. We're learning a ton fast.
Right now this whole project is very alpha work and we'll learn as we go!
That being said, would love to add support for other wasm based languages and start finding patterns and places where we can improve the experience :)
thanks @kennethcassel , that's very clear and reasonable. 🙏
I would love to see TS support as well. All of this is quite overwhelming to me, tbh. Took me a good few hours to get some understanding of how this works.
If I'm not wrong, if we were to work on trying to add TS ( / AssemblyScript) support, we'll need a TS equivalent of Pyodide?
@Dhaiwat10 I think most of us are learning! A great place to start is https://wasmbyexample.dev to learn more about how the web and wasm interact.
For TS I think it's somewhat of a special case (since JS runs natively in the browser). We could go down AssemblyScript route or we could go the route of allowing a user to write TS, compile, then show the output through a javascript evaluation in browser.
Here are nice resources for different language support https://github.com/appcypher/awesome-wasm-langs https://github.com/mbasso/awesome-wasm
These seem relatively easy to implement:
Another project I contribute to The Arcane Algorithm Archive has a rather extensive list of languages that people contribute in. I would love to try and support most of them so we can finally close our issues on running the examples in the browser
Our list of languages we support is visible here and will be at the end of this comment.
I would love to support as many of these as possible. I do understand that some of them are esolangs so reaching 100% completion isn't needed.
Language List
Julia
Bash
C#
C++
C
chip-8
Python
JavaScript
Scratch
Haskell
Rust
OCaml
Java
Clojure
Elm
LabVIEW
D
Go
Swift
Racket
Matlab
R
TI-83 Basic
Lua
Crystal
PHP
Common Lisp
Nim
X86-64 Assembly
Fortran90
Factor
Whitespace
Scala
Emojicode
LOLCODE
Piet
Scheme
PowerShell
Vlang
CoffeeScript
Kotlin
TypeScript
VimL
Coconut
Dart
Some thoughts as I'm passing through...
Most if not all interpreters can be compiled to wasm32-wasi just fine without much trouble, minimal of any maintaince required.
For compiled languages however it gets a bit more complicated. While it is possible (and technically feasible) to compile clang, rustc and so forth to WebAssembly, Ben Smith for example did get clang running with a very basic WASI shim for example.
The problem with this approach is that such a build requires a lot of effort to be maintained and kept up with date as upstream comes out with new releases. Where-as an endpoint which simply invokes the toolchain with wasm32-wasi or wasm32-unknown as the target is a dead simple write once and be done with it approach.
This sort of endpoint is stateless as-well so can be served from more or less any kind of configuration, be it from FaaS, PasS or just locally. Can also cache this kind of output very aggressively based on the source input, compiler args and compiler target.
This is how things like http://webassembly.studio work, the server does the build and the client does the running.
I wouldn't try too hard to support other system calls than the The WebAssembly System Interface, it isn't perfect in that it's missing things like sockets but it gets you quite far. Emulating all the features in said system interface isn't trivial but it is quite feasible. Note tho at this point in time, most calls do have to be "asyncified" via Binaryen as blocking i/o still isn't a thing browsers altho there are various proposals trying to solve this at the native browser level.
Also take a peek at things like https://webassembly.sh, https://wapm.io
Language List
Julia Bash C# C++ C chip-8 Python JavaScript Scratch Haskell Rust OCaml Java Clojure Elm LabVIEW D Go Swift Racket Matlab R TI-83 Basic Lua Crystal PHP Common Lisp Nim X86-64 Assembly Fortran90 Factor Whitespace Scala Emojicode LOLCODE Piet Scheme PowerShell Vlang CoffeeScript Kotlin TypeScript VimL Coconut Dart
Can I open an issue for each of these languages?