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

171–180 of 520 posts

Re: WASM 3.0 Completed

#171

Post by mixedCase »

bborud wrote: post #65

I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution. If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.

You're doing native code, this the solution is the same as in native code: your languages agree on a representation, normally C's, or you serialize and deserialize. Mixing language runtimes is just not a nice situation to deal with without the languages having first class support for it, and it should be obvious why.

Re: WASM 3.0 Completed

#172

Post by IshKebab »

poly2it wrote: post #168
tjoff wrote: post #148

Earlier quoted context omitted.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

It doesn't actually allocate 4 GiB. Memory can be mapped without being physically occupied.

No, web apps can actually use 4GB of memory (now 16GB apparently).

Re: WASM 3.0 Completed

#173

Post by Jtsummers »

zb3 wrote: post #169
Jtsummers wrote: post #143

Earlier quoted context omitted.

Multiple memories and Memory64 just became part of the spec. And JSPI is still being standardized. Is Safari slower to roll out new things? Yes. But it's hardly stopping adoption. Chrome has 70% of the browser market, Safari barely has 15%.

But Apple doesn't allow using other browser engines on iOS, so this matters much more. I mean, they were forced to allow them, but of course they didn't actually comply, they created artificial barriers to ensure only Safari can be used on iOS. EDIT: By "safari" here I actually mean WebKit.

For the mobile browser market, Chrome is still around 70%, Safari is a bit better off in mobile at 20% of global browser market share. That's still a minority platform. It's not inhibiting wasm feature adoption with those numbers.

Re: WASM 3.0 Completed

#174

Post by alabhyajindal »

titzer wrote: post #136
alabhyajindal wrote: post #123

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating. Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well design…

What were your specific pain points? One thing that can be annoying is validation errors. That's one of the reasons that Wizard has a --trace-validation flag that prints a nicely-formatted depiction of the validation algorithm as it works.

Validation errors were bit of an issue. Especially because Binaryen constructs an internal IR that remains opaque until we emit the Wasm text. I did consider Wizard for my project but settled on Wasmtime because I needed WASI support.

My major pain point was the documentation. The binaryen.js API reference¹ is a list of function signatures. Maybe this makes sense to someone more experienced but I found it hard to understand initially. There are no explanation of what the parameters mean. For example, the following is the only information the reference provides for compiling an `if` statement:

  Module#if(condition: Expression, ifTrue: Expression, ifFalse?: Expression): Expression
In contrast, the Wasm instruction reference on MDN² is amazing. WASI again suffers from the same documentation issues. I didn't find any official resource on how to use `fd_write` for example. Thankfully I found this blog post³.

Wasm feels more inaccessible that other projects. The everyday programmer shouldn't be expected to understand PL research topics when they are trying to do something with it. I understand that's not the intention but this is what it feels like.

1. https://github.com/WebAssembly/binaryen/wiki/binaryen.js-API

2. https://developer.mozilla.org/en-US/docs/WebAssembly/Referen...

3. https://tty4.dev/development/wasi-load-fd-write/

Re: WASM 3.0 Completed

#175

Post by afiori »

jsheard wrote: post #104
renehsz wrote: post #97

Earlier quoted context omitted.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

Honestly you could allocate a new memory for every page :-)

Re: WASM 3.0 Completed

#176

Post by jjcm »

tjoff wrote: post #148
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

I know you're in this for the satire, but it's less about the webapps needing the memory and more about the content - that's why I mentioned video editing webapps.

For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buffer this into memory. It's why most modern video editing machines are sold with 64-128GB of memory.

In the case of Figma, we have files with over a million layers. If each layer takes 4kb of memory, we're suddenly at the limit even if the webapp is infinitely optimal.

Re: WASM 3.0 Completed

#177

Post by miniBill »

tjoff wrote: post #148
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

In fairness, this is talking about Figma, not an email client

Re: WASM 3.0 Completed

#178

Post by hsbauauvhabzb »

tjoff wrote: post #148
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

Finally a web browser capable of loading slack

Re: WASM 3.0 Completed

#179

Post by afiori »

re wrote: post #75

I haven't really been following WASM development in the last year and didn't realize that WASM had moved to a versioned release model. I've been aware of the various features in development[1] and had thought many of the newer features were going to remain optional but I guess now that implementations are expected to support all the features to be able to claim compatibility with e.g. "WASM 3.0"? It'll be interesting…

I suspect the versioning is going to replicate the JavaScript version system where versions are just sets of features that a runtime can support or not, I am not sure how feature discovery works in wasm though

Re: WASM 3.0 Completed

#180

Post by cedws »

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?
Post reply on HN