Hacker News Reader

Comment by pmontra | Hacker News Reader

> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.

Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many people writing SPAs in C++ for the extra speed (let's say, the JS layer acting like an X Server for the DOM, driven by a C++/WebAssembly application). Games, yes.

Furthermore JS has view source. WebAssembly has a text format [1] but it's really assembly. Hopefully there will be source maps [2].

[1] http://webassembly.org/docs/text-format/

[2] http://webassembly.org/docs/tooling/

View on HN

You don't have to go back to the 80's to develop closer to the metal. Neither Rust nor Swift have garbage collection, but both are thoroughly modern, productive languages. I've also been told that C++14 is reasonably pleasant, but I have no personal experience with which to judge.

Swift is garbage-collected – it might not have a tracing GC, but ARC is essentially compile-time GC – certainly, from the perspective of a developer, ARC is extrordinarily similar to a tracing GC (with some small caveats).

Reference-counted GC is trivially implemented on top of WebAssembly memory model.

"compile-time GC" sounds like it would apply to C/C++'s automatic storage duration too.

The lack of GC is a benefit here. Remember, WASM as an MVP is meant to bring C/C++ codebases on the web.

There is plenty to be excited about here. This will enable faster [media apps, games, etc](http://webassembly.org/docs/use-cases/) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it.

Edit: HN really should support a few more formatting options.

It's not a benefit, it's simply a temporary compromise to get it out faster.

There are a lot of developers -- a huge amount, actually -- who believe memory management is too important to leave to an automated GC algorithm. That, and the memory requirements of a particular application might require something different than a GC provides.

If your algorithm is such that everything can be placed on the stack then GC gets you nothing.

A lot of GC languages don't give you access to the stack, though, all objects live in the heap.

Isn't WASM a compile target?

It doesn't prevent a language from adding its own GC.

At least in Rust's case, RAII/lifetimes provide mostly the same development experience without GC overhead.

Reply on news.ycombinator.com