Oh yeah, you can definitely request more memory! But you don’t see two ArrayBuffers in JavaScript. You see one ArrayBuffer that grows. Or viewed from the C/Wasm side, one linear memory that grows. I’m sure the runtime is hiding all sorts of magic though.
Yep. That’s part of the complexity I was talking about! It’s all achievable, it’s just more complex. There are two regions being managed in completely different ways and there are side-interactions between them. So every time you do something in one region you have to mess about with the other region too. I have a sense that more edge cases will emerge, because it’s complex in the Rich Hickey sense of things being intertwined. And that’s kind of normal for GCs! It’s still way simpler than V8’s Orinico, for example! It could be a good direction for the future!
Hi. It’s very interesting topic.
I just want to add some Rust libs for inspiration, because I’m writing a Rust framework and I’ve rewritten Richard’s RealWorld example to it a few months ago, so I think that Rust-WASM world is mature enough.
Thanks for sharing!
As I mentioned in the README of my repo, I don’t think my Rust skills are advanced enough for this, but if someone who knows it better wants to do a project like this I will gladly give them some pointers… #dadjokes
Hey everyone, thanks so much for all the comments, this has been a fantastic thread!
I’ll do some more posts whenever I have news to report. Here’s roughly the next steps as I see them right now. This could obviously all change.
Create a wrapper or interface between a WebAssembly module and Elm kernel JavaScript.
Get that interface working for a “hello world” app with the main parts of TEA (update, view, etc) in Wasm and the Elm kernel in JS
Figure out what memory management issues there are when crossing the language boundary. (What if Wasm’s memory overflows when JS writes to it? Does Wasm need to refer to JS objects, and if so, how? How to deal with onClick handlers as discussed above?)
Finish code generation for the full Elm AST (outputting both C and JS). Compile some proper programs and play around with them.
Do some analysis on memory profile or real programs, what runs fast or slow, etc.
Try migrating VirtualDom diffing to Wasm, with JS just applying patches.
Look into further GC optimisations for VirtualDom as suggested above
My general approach is to explore all the different pieces, then work on the biggest unknown until I understand the important issues and/or solved some problem. Once I feel like I understand that well, move on to the next biggest unknown.
This means gradual progress on lots of pieces in parallel, with no end-to-end system for quite a long time. I’ve been told this approach seems weird to some people, but it’s how I do it. I feel it will lead to good design choices.
I’d like to have good docs on this so I’d welcome GitHub issues on that particularly.