Hacker News Reader

Comment by overgard | Hacker News Reader

Honestly I'd only use C and C++ with this. It's not going to be a good target for anything that currently requires a VM (most garbage collected languages)

View on HN

Rust doesn't require a garbage collector

Or a VM, or (in the extreme) even a memory allocator (which is how it gets by on microcontrollers).

Unless I'm missing something, I think most languages will be fine. I'd think pretty much every language will need to cross-compile their runtime library to WASM, which would include their garbage collection. C/C++ will obviously be easiest to map onto WASM, but I'm guessing other languages won't be too far behind. LLVM already has a WASM target.

Garbage collectors are not always very portable. e.g. conservative stack scanning is not possible in WASM.

In the current version or will never be?

Why not? Once someone implements a good-enough garbage collector that can be used by a multitude of garbage collected languages.

Different langauges demand different features in the implementation of a garbage collector. A garbage collector that every language implementation could use would basically be a set of functions that languages could use to implement their garbage collectors, but at that point the library would be tiny and the per-langauge implementation of garbage control would be huge.

I'm not sure that the garbage collector in Ruby, Python, Node.js or Perl is going to be radically different. They all have their own implementations for historical reasons, not because they have such wildly different concerns.

Java has a strange way of handling object lifetimes that complcates things, but it's not the norm.

Well you can't even compile Ruby, Python, Node, or Perl to WASM, since you can't compile dynamic scripting languages to LLVM. You could, for example, interpret Python by compiling the CPython interpreter to WASM (though that would mean an absurd bundle size), but this doesn't solve your problem since the python garbage collector is in the CPython source and you can't just remove it nor can you use a different langauges garbage collection because every language represents objects differently.

> you can't compile dynamic scripting languages to LLVM...

Considering Rubinius uses LLVM that's not quite true, and further, just because people haven't succeeded in taking it all the way it doesn't mean you can't. Maybe it's just hard.

For example, if you're willing to sacrifice a few features that make compilation difficult you actually can compile Ruby: RubyMotion (http://www.rubymotion.com/tour/how-it-works/) does it.

The biggest problem is something like eval, but if you're willing to live without dynamic features like that you don't have a lot of impediments to compiling to LLVM.

Most garbage collected languages don't require a VM as far as I'm aware. D, Go, Lisp, Scheme, Haskell, ML, Nim, ...

How come? I thought WebAssembly was designed with GC in mind.

Reply on news.ycombinator.com