Hacker News Reader

Comment by preommr | Hacker News Reader

On gc:

> Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm.

There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc."

This is not a silver bullet. Cpp, or rust are probably still going to be the way to go.

Relying on the GC features of WASM will require writing code centered around the abstractions for the compiler that generates WASM.

View on HN

I thought that the purpose of GC in WASM was to allow such higher level languages to be placed there without a bulky runtime also in WASM.

What's the value proposition of WASM GC if not this?

As I understand it, WASM GC provides a number of low level primitives that are managed by the WASM host runtime, which would theoretically allow languages like Go or Python to slim down how much of their own language runtime needs to be packaged into the WASM module.

But how those languages still need to carry around some runtime of their own, and I don't think it's obvious how much a given language will benefit.

>But how those languages still need to carry around some runtime of their own

Also just there will be a special version of those language runtimes which probably won't be supported in 10 years time. Just like a lot of languages no longer have up to date versions that can run on the common language runtime.

Programming languages with type erasure would have no runtime, just raw program code and the WASM GC. Languages that have runtime types still need a runtime for that functionality.

The Kotlin wasm compiler was basically engineered on top of wasm's GC support. Works fairly OK. As far as I understand it's essentially the same garbage collector that is also used for regular javascript.

> This is not a silver bullet. Cpp, or rust are probably still going to be the way to go.

I don't think that's necessarily true anymore. But as you say, it depends on the compiler you use and how well it utilizes what is there. Jetbrains has big plans with Kotlin and Wasm with e.g. compose multiplatform already supporting it (in addition to IOS native and Android).

Dart is in a more advanced state in that front.

This isn’t true at all in Dart for example which is a WASM-GC language. Literally one of the very main selling points of Dart is you write your code once and it runs anywhere, WASM is just another compile target like x64 or RISC-V or iOS.

Wasm-GC are abstractions for compiler writers to enable GC dependent languages to run without shipping a GC to run inside the already GC'd browser/Wasm heap and instead just use the browser GC directly.

So yes, Java,C#,etc will work better (If you look at the horrible mess the current C# WASM export generates it basically ships with an inner platform containing a GC), and no, it will explicitly not speak with "javascript" objects (you can keep references to JS objects, but you cannot call JS methods directly).

C# cannot be compiled to WASM GC yet: https://github.com/WebAssembly/gc/issues/77.

The two main benefits of wasm GC are that compilers can avoid implementing or compiling a full GC but also that the guest and the host can share structured data types

That was the hope but unfortunately the browser can't do anything with WASM GC structs, not even read them!

Reply on news.ycombinator.com