What are the actual benefits of compiling to wasm rather than JS? One drawback is that, at least for the near future, a wasm module has its own heap rather than participating in the garbage-collected heap of the JS engine. It’s also likely that wasm means a larger runtime footprint.
Betting on future states of technology maybe?
How is that a benefit? I would agree if compilation to WebAssembly avoids GC, but Grain seems to require GC anyway.
Yes, but you get to pick and ship the GC for your application.
I see no benefit. I said the same thing for Go WebAssembly backend; there is already GopherJS.
I read the examples thinking, hey, this looks and works a lot like ocaml with different syntax — even the way it handles mutability is the same. And it turns out it is built in ocaml! Nice. I didn’t look further to see if it’s compiling to ocaml and then to wasm under the hood, but I wasn’t aware ocaml had a wasm target so perhaps it’s all just a coincidence.
Roughly promising no runtime exceptions (a) doesn’t instill confidence and (b) exceptions are a feature not a bug. Surely a vastly overused feature, but a feature nonetheless. Pony is a language with an actual guarantee of no runtime exceptions and it makes some serious compromises to achieve that: types are sometimes more complex to track exceptions and division by zero is nonsensical. I’d need a more thought out argument from grain rather than just “it’s 2018”. That said, it looks like a cool project overall
There is apparently an ‘instruction’ with constructor ‘MError’. https://github.com/grain-lang/grain/pull/20/files#diff-927705db37dc34525f280901b665b1eeR109
Seems unlikely that it would have absolutely no runtime errors.
Ah, well then “No runtime exceptions, ever.” is a little misleading \(*.*)/