> We have a number of big challenges in the immediate future, but I think the biggest one of all will be the long tail of compatibility and correctness issues
No kidding... how about get it roughly working on hacker news, and make it the hackers way to start each day, and pull in as much help and community as possible from here?
A big advantage of WasmGC is it would allow your binaries to be smaller, since you wouldn't need to bundle an allocator for heap::alloc and free. Kotlin and Java binaries can in some cases be be much smaller than C++ and Rust for that reason.
So I have not yet tried out this aspire, but my gut feeling (as a long time dotnet dev) is that this will turn into a tangled web of complexity down the road.
We have a pretty minimal setup at formancehq/ledger[1] that uses pg as a storage backend, and comes with a programmability layer to model complex transactions (e.g. sourcing $100 from three accounts in cascade).
Between these sorts of email tricks and ability to easily voice clone using ai, it would seem that invoicing systems should put some sort of 2 factor approval/confirmation into the workflow for payouts.
I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.
Last year chrome started discarding background tabs to save memory, probably should have said discard rather then sleep it's been a while since I worked on that. Our user base keeps tabs in background often in mobile devices and we saw some reports of it. https://arstechnica.com/gadgets/2023/02/chrome-110-will-auto...
When you do an htmx navigation to a new page, a discarded tab will "restore" only the last htmx fragment loaded, not the entire html page with style tags. Fix is to use unique url on push that isn't in local cache which forces a server reload on tab wake from discard.
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.
> 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.
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.
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.
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.
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?
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.
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.
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.
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...
No kidding... how about get it roughly working on hacker news, and make it the hackers way to start each day, and pull in as much help and community as possible from here?