[ledgerdev]

From my perspective It's 2 primary blockers.

1. It's too damn hard to get data into and out of wasm modules. The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first.

2. Lack of GC which has made languages like js/python/jvm/c# unfeasible. WASM GC is just now available and hopefully ship compilers can target and build wasm modules that aren't so large in not too distant future.

Once we are past these 2 items, wasm can run free and really should become the final unit of deployment.

edit: I also suspect that like the jvm which started as a client tech, wasm will find more use on the server side, than on the client side in info/business type software.

[phickey]

> The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first.

As someone who works on the Component Model, this perception is interesting to me, can you explain your thinking a bit more? From my perspective, getting data in and out of modules is indeed solved. Worlds are a type signature that describe what datatypes and methods are available in a particular embedding, with standards for command line and http proxies, but easy to define whatever your situation requires.

[digdugdirk]

As someone who wanted to try to use WASM ~1yr ago, I was unable to find any reasonable way to get data in/out of wasm from the local environment, and gave up on trying to learn it because of this.

Could you please provide links/info for how to do so? I want to be able to learn how to use it, but without this ability it seems entirely useless for me.

[phickey]

Some of my colleagues have built https://component-model.bytecodealliance.org/ to help get folks up to speed. The best place to ask questions is in the bytecode alliance zulip: https://bytecodealliance.zulipchat.com/

[nilslice]

Yep, this is one of the initial motivations for creating Extism: https://github.com/extism/extism -- and it works across 16 host languages & 8 guest languages.

[ledgerdev]

What host language and guest language would be top of list? I have some a few working I have been playing with.

[neuronicnobody]

For #1, check out https://extism.org/

[andsoitis]

> Lack of GC which has made languages like js/python/jvm/c# unfeasible.

I've had success running F# (a .NET language, like C#) on WASM using Bolero: https://fsbolero.io

[kevingadd]

Sadly the current iteration of WASM GC is still too limited for stuff like JVM or C# garbage collection semantics without jumping through a lot of hoops. I'm optimistic that in a few years there will be an expanded version of it that more runtimes can adopt, though.

#1 is a pet grievance of mine though. The intentional choice not to build mmap or read-only pages into the WASM memory model is really frustrating.

[ledgerdev]

I've been wondering how WASM GC works with multiple wasm modules, it sounds like you might know. Does WASM GC exist outside individual modules managing memory for many, or is it "contained" inside each module? Does it allow for efficient sharing and minimal copies of memory between modules when host calls both?

For example say you have some data like (eg. string "abc123") in host memory and then pass into module A which then reads/operates the data, and then returns some other data to the host. The host then calls into module B passing the original host data and data returned from call to module A. Can that original host data be shared efficiently and managed by WASM GC between modules?

[kevingadd]

I'm not aware of any reason why what you're describing wouldn't work. At least in a browser tab, all the wasm modules will share the same JavaScript GC heap, so the string data should be sharable between the modules if it's passed around as a GC reference.

[titzer]

Are you referring to the weak references or to interior pointers? What I've been surprised by over the years it that a simplified, perhaps slightly broken version of a language comes to Wasm first, then as features expand, more of the guest language features, libraries, platform, and ecosystem comes, piece by piece. CheerpJ claims to have a fully-featured JVM, and Google is fielding Java compiled to Wasm GC with pretty good results. Wasm is bringing these platforms over piece by piece; so far there haven't been few "boom, here's full Language X on Wasm" moments. Instead we're progressing quite incrementally.

[kevingadd]

Interior pointers and WRs are both basically mandatory, yeah. I have faith they'll arrive eventually.

I think incremental progress is generally great, but since we already have 'all of .NET' in WASM by shipping our own GC, end users seem like they wouldn't be happy with 'we use WASM GC now and all of your code is broken'

EDIT: We also have dependent handles in a few places, and I'm not sure how you'd do those without a more sophisticated GC. But it's probably possible and they're at least not used as widely as WRs.

[neonsunset]

Quite a bit of code may end up relying on a CWT because a dependency uses assembly-unloading-friendly cache internally, hopefully it fails gracefully once .NET switches to WASM GC...

[pjmlp]

> Lack of GC which has made languages like js/python/jvm/c# unfeasible.

If they weren't feasible, there wouldn't be several implementations shipping for several years now.

Just like a typical hardware CPU that isn't a *Language XYZ Machine", GC implementation ships with the runtime.

[ryukafalz]

Yeah, I think the GC bit was one of the huge missing pieces for dynamic languages on Wasm. Things seem to be moving very quickly now that Wasm GC is out there: https://spritely.institute/news/building-interactive-web-pag...