Comment by dfajgljsldkjag
16 hours ago
It is interesting to see another language target WebAssembly especially one like Racket. The fact that it compiles to a subset of the language limits its utility right now. I think it is a neat proof of concept but it needs full language support.
For folks curious about the supported language subset, here's a summary:
- Modules aren't implemented yet, but are high on the list
- Continuation-based control flow isn't supported yet, including break and promises. Tail calls are supported though.
- No support for complex numbers, bignums, weak hashtables, immutable hashtables, prefab structs, regexp, or file I/O support
Most of the rest of racket/base should work, according to the README. There's also a FFI for javascript, including bindings for Math, DOM, Canvas, MathJax, XTermJS, and JSXGraph. Overall feels like you can use most of the language right now unless you need odd Racket-isms or call/cc.
check out grain! https://grain-lang.org/
I don't know that there are any similaries besides the names -- well maybe something thematic about distributing the future or what looked like it at the time to more programmers -- but the handful of times I've run across Grain (probably all on HN) I'm reminded of Wheat https://web.archive.org/web/20050215032130/http://wheatfarm....
As far as I know compiling full Racket to WASM is impossible because of continuations.
I wouldn't say compiling full Racket to WebAssembly is impossible. But I think the consensus is that one can't add a WebAssembly backend to the compiler in the same manner as the x86 and arm backends. These backends manipulate the stack in ways WebAssembly prohibits.
This forces an Racket implementation to make continuations explicit. And that will most likely mean a WebAssembly backend will be slower than the native backends.
You could probably model continuations using the wasm GC feature since you can then pass around function references and strongly typed continuation objects, but making it work certainly wouldn't be trivial.