Hacker News Reader

Comment by tyingq | Hacker News Reader

I'm somewhat curious at what pace WASM will gain "market share" while it's only practical to target it with C, C++, Rust, etc.

Supposedly, there are plans to expand it to where it looks more like a virtual machine and less like ASM. Adding things like garbage collection, direct DOM manipulation, polymorphic inline cache, etc. Things that would make it possible to run a decent scripting language without pulling in some huge runtime.

Or forgetting the scripting languages, just the direct DOM access might make it less tedious to use with compiled languages.

It's sort of a second run at getting "applets" right, but in a cross-language way.

View on HN

> Adding things like garbage collection, direct DOM manipulation, polymorphic inline cache, etc. Things that would make it possible to run a decent scripting language without pulling in some huge runtime.

Doesnt this just imply building a 'huge runtime' into the language?

Not necessarily. GC can be implemented in a way that's fairly compatible with low-level programming, by leveraging support for multiple address spaces and/or memory segmentation. And WASM needs that kind of support anyway for its planned module-based security.

FWIW, AssemblyScript[0] adds its own garbage collection runtime into Wasm. The team had a good post recently on the performance implications[1]

[0] https://www.assemblyscript.org/

[1] https://surma.dev/things/js-to-asc/index.html

Not sure I understand. If parts of the runtime are already in the browser, then there's less to download.

> Things that would make it possible to run a decent scripting language without pulling in some huge runtime.

Seems to me the web already has an answer for that: transpile to JavaScript, and leverage the existing high-performance JavaScript engines.

Dart does this, for instance.

Graalvm native image has the ability to target llvm with a goal of making it easier "to target a new architecture without having to implement a complete new backend for Native Image."

https://www.graalvm.org/reference-manual/native-image/LLVMBa...

> while it's only practical to target it with C, C++, Rust, etc.

You might not want to bundle Rust in with C and C++ in this context. Rust is pretty accessible to developers coming from scripting languages (JavaScript, Python, etc).

Direct DOM manipulation (and the ability to send reference types across the JS-wasm boundary) is a pretty big deal though I think. Currently it doesn't make an awful lot of sense to build code that interacts with the DOM in WASM (although in Rust there are automatically generated bindings that go through a JavaScript shim).

> Rust is pretty accessible to developers coming from scripting languages (JavaScript, Python, etc).

Not in a way that is unique to Rust…

I think WASM success won't be measured by market share gain on the web, but by number of new non-browser things that are programmed with WASM.

Agreed. An interesting example is the new Microsoft Flight Simulator, which uses WASM[0] as a sandboxed language to create airplane gauges and custom flight models (HN discussion[1]).

[0]: https://forums.flightsimulator.com/t/getting-started-with-wa... [1]: https://news.ycombinator.com/item?id=24281400

Very Cool!

In that specific situation I find it very uncool. It's targeted only by C++, a language that is far too complex to have any business being used as a scripting language to make needles move on a virtual altimeter. You get all of the drawbacks with none of the benefits of a C++.

I don’t find it uncool at all. Well we have to start somewhere. Don’t you think this usage of WebAssembly is at least providing some feedback into it’s ecosystem to make improvements for next time? Id rather have developers choosing webassembly even if the implementation doesnt meet our expectations yet

EOS blockchain contracts are compiled to WASM.

it seems more like it's it's trying to be LLVM but for the web?

Reply on news.ycombinator.com