Hacker News Reader

Comment by 6nf | Hacker News Reader

What languages do you all recommend for compiling to Wasm? I know Rust is an option and something like Nim would probably work well. What is the future of Wasm?

View on HN

WASM is going to make Rust [1] shine like nothing before. I love that all the Mozilla articles keep mentioning it together with C/C++.

Unfortunately, writing Rust is an order of magnitude more difficult thatn writing ECMAScript, so hopefully it doesn't create a negative response from hordes of ES developers that want to check out this WASM thing.

But it's so much more suited than C/C++ (the other obvious candidates). In a nutshell, WASM is not really intended for higher-level languages with garbage collectors, etc. For that kind of work, I'd stick with ECMAScript.

[1] : https://www.rust-lang.org/

There's been a reasonable amount of success for JS programmers moving to Rust; npm is now using it for backend services, for example. There is a big semantic gap, but many don't find that insurmountable.

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)

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.

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

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?

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

Reply on news.ycombinator.com