This is an idea a have about how to help people understand elm in relation to javascript.
I am coming from 22 years of JavaScript use.
JavaScript is nuts - i’ve seen things in JavaScript that boggle the mind.
Elm has been likened to a straight-jacket for JavaScript - actually it’s more like therapy for the browser and for JavaScript programmers.
I’m sorry to say: JavaScript is terribly useful - it’s also plain terrible - this is a fact.
it’s nice that people have things like flow and typescript - however it’s still actually JavaScript. Javascript with some bare bones yoga classes and a few mindfulness training seminars and a bunch of support groups - it’s not going to take us away from all the inherent problems of JavaScript as JavaScript - Even if you are enlightened enough to carefully and masterfully only use the good parts.
I’m grateful for the vision of Elm - it doesn’t need to compromise - it’s a small growing tree - it’s a baby tree that we can see is going to be massive and strong just from how well and healthy its’s roots are.
That doesn’t make it a grown tree and hanging all sorts of ornamental garbage off it isn’t going to help it grow tall and strong.
Thank you to the adopters that are strong and flexible enough to help steward its growth - the garden of elm has many needs for many hands - however it what it doesn’t need is to be something that it is not - and it sure as hell isn’t JavaScript - that’s just the runtime of the moment.
The funny thing here is that you should be one of the people writing the JavaScript still needed by Elm, not me. With so much JavaScript experience you are superbly qualified to design the minimal, safe JavaScript needed for driving some functionality that might be needed in Elm.
And will continue to be the runtime of Elm at least 3-5 years into the future.
Guesstimation based on the fact that there is no GC in webasm yet. Once that’s done, it will still take some time until all major browsers will implement it and then it will probably be shipped behind a flag for a time. I doubt that an official webasm port will start before at least there is some official GC support in webasm to allow for easy experimentation.
Of course, unofficially, someone could implement an Elm compiler that would output C or Rust and compile that to webasm but the results would probably not be optimal. The runtime alone might be in the hundreds of kb. However, I might be wrong…
The good news is that Elm might be one of the languages that could be used to optimize the GC for target code from functional programming languages.
I’m aware multi-threading and garbage-collection was on the roadmap for wasm (I’ve been following the stuff on Github about it) - But there isn’t any dates on any of that wasm stuff, is there?
I’m currently going through the Rust programming book and having a lot of fun trying to digest the ideas Rust is built on really cool stuff
I’m not currently aware of a core set of “JavaScript still needed by Elm” is this documented?
It is interesting that you bring this up as i’m currently focused on small ways that Elm can replace Javascript in existing codebases to improve quality and reduced errors.
I could see that the core compiler team may want to implement features that write elm into “the javascript that is needed” to interface with various esoteric parts of the browser s javascript runtime.
I’m not aware of WASM’s spec or roadmap though i have worked with ASM.js - I would expect that the actual details of memory management would be part of the browser layer - and routines in WASM would integrate with that existing or future memory management system ( this is what something like “new” does now - integrate with the nuances of the browser’s allocation runtime)
AFAIK the problem is that right now you would need to implement your own garbage collector on top of the single chunk of memory that is assigned to your app while a perfectly battletested one lives just around the corner in the browser. You could do it but there’s really not much sense in doing so, you’ll never match the man-hours put into say Chrome’s garbage collector. Rust can run right now because they have memory management inside the language via their borrowing system.
From what I’ve gathered the roadmap is indeed very vague but it was mentioned that they want to bring DOM handling APIs into WASM, which right now you can only do Elm style via “ports” to the outside context. Some time after that supporting the browser garbage collector is scheduled… but that has also been the case for ASM.js sooooo, we’ll see whether that ever happens and if it does when this is due.
A very good and recent talk can be found on the GOTO Conference YouTube. I’d regard that as the number one source on WASM right now.
Regarding the GC: I recall that Evan wrote on one of the mailing lists that removing the possibility of cyclic pointer structures in Elm is something he’s considering. That would enable plain old reference counting a valid memory management strategy. That would simplify things. Still, a WASM target would be a major piece of work.
If you use the LLVM compiler framework to generate your WASM code - it already includes a lot of support for garbage collection. It does not provide a complete ready made GC, because the exact implementation always depends on the language, but it does provide a lot of tools to build one. So writing the garbage collector may not be such a blocker as people think.
Also, GC version 0.01 - just start simple with a pause-the-world mark-and-sweep collector. Good enough to get started, then refine from there.
With the current context where one would have to implement and ship the GC with the deliverable and suffer the penalty of calling the DOM from webasm there might be a lot of effort for no benefits.
I would love to be proven wrong about this but I seriously doubt it can be done without some kind of Mike Pall level of competence.
This seems to be the current mind-set. If we stay that way, WASM is just something we talk about and never do.
There are a couple of folks experimenting with compiling Elm or similar/sub-sets to WASM that I hear about now and again on Slack. To me this is much more encouraging; just get stuck in and have a go, there is a lot to learn and figure out.
I wrote a Prolog compiler once - it had no GC so was just a toy; after running for a while it would run out of heap space and crash. I was hung up on the GC because it seemed difficult. Eventually I wrote a simple mark and sweep collector in about a day (you can find the algorithm in a text book), and then wondered why it took me so long to do that. Of course, my pause-the-world collector isn’t the best that could be done, but it was a major step forward for a small investment of effort.
@ElmModerationTeam Hi… Is it possible to fork this conversation about garbage collection - it seems like people are really interested in talking about it.
Garbage Collection folks : Maybe we could talk about ways that we try to take care of javascript now that elm now can solve for us?
For example : I want to have a client service to a remote backend service do non-critical to user flow work - but and i need to guarantee that my “client service” is not going to crash or impact the user experience.
An Elm worker with a port filled this niche nicely.
@rupert@ram9cc that’s true ASM is more of a Mozilla pet project but the same people who worked on that at Mozilla seem to be in the same boat with the former NaCl staff of Google so there is indeed hope. LLVM might be an option but you’d still need to write a backend for that.
really cool stuff
