Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

41–50 of 520 posts

Re: WASM 3.0 Completed

#41

Post by AgentME »

aag wrote: post #8
WhereIsTheTruth wrote: post #6

> GC and Exception handling This was not necessary.. what a mistake, specially EH..

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.

Re: WASM 3.0 Completed

#42

Post by pbiswal »

phickey wrote: post #34
pbiswal wrote: post #18

Is the component model work ( https://component-model.bytecodealliance.org/ ) related to the 3.0 release in any way?

No, the component model proposal is not part of the Wasm 3.0 release. Proposals only make it into a Wasm point release once they reach stage 5, and the component model is still under development and so is not trying to move through the phases yet. Unlike any of the proposals which became part of Wasm 3.0, the component model does not make any changes to the core Wasm module encoding or its semantics. Instead, it’s de…

Thanks for clarifying.

Re: WASM 3.0 Completed

#43

Post by boricj »

MangoToupe wrote: post #26
boricj wrote: post #24

Does WASM still have 64 KiB pages? I get why for desktops, but there are use-cases for running WASM on microcontrollers where that's either inconvenient or outright impossible. The one in particular I have in mind would be to put WASM on graphical calculators, in order to have a more secure alternative to the ASM programs (it's possible nowadays to write in higher-level languages, but the term stuck) that could work…

Why WASM and not, like, java or something?

As in, Java ME?

Unless I'm mistaken, it's been on life support for the past 15 years. It's probably more heavyweight and firmware size/Flash usage is a concern. I don't think performance would be on par with WASM and there are use-cases where that really matters (ray tracing rendering for example). I'm also not sure there are many maintained, open-source implementations for it out there. I've also heard stories that it was quite a mess in practice because it was plagued by bugs and quirks specific to phone models, despite the fact that it was supposed to be a standard.

I'd gladly be proven wrong, but I don't think Java ME has a bright future. Unless you were thinking of something else?

Re: WASM 3.0 Completed

#45

Post by TUSF »

john01dav wrote: post #29
preommr wrote: post #22

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 b…

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.

Re: WASM 3.0 Completed

#47

Post by davey48016 »

onionisafruit wrote: post #31
bryanlarsen wrote: post #23

Earlier quoted context omitted.

The fact that a minimum size go program is a few megabytes in size is acceptable in most places in 2025. If it was shipped over the wire for every run time instead of a single install time download, that would be a different story. Garbage collection is a small part of the go run time, but it's not insignificant.

I will be interested to see if Go is able to make use of this GC and if so, how much that wasm binaries

https://github.com/golang/go/issues/63904

Skimming this issue, it seems like they weren't expecting to be able to use this GC. I know C# couldn't either, at least based on an earlier state of the proposal.

Re: WASM 3.0 Completed

#48

Post by diego_moita »

There's a joke in Brazil saying "Brazil is the country of the future and will always be that. It will never be the country of the present".

WASM is and will always be the greatest technology of the future. It will never be the greatest technology of the present.

Re: WASM 3.0 Completed

#49

Post by Imustaskforhelp »

hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

I wish the same mate, Please wasm team, I am more than happy waiting 3 years if you can guarantee that you are looking into the best way possible into integrating this feature of dom manipulation.

I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably.

Please give us more freedom! This might be the most requested feature and this was how I came across knowing wasm in the first place (leptos video from some youtuber I think, sorry if i forgot)

Re: WASM 3.0 Completed

#50

Post by jillesvangurp »

preommr wrote: post #22

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 b…

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).

Post reply on HN