Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


I am not sure what you actually want but it sounds like something where the component model (the backbone of WASI) might help.

It defines a framework to allow modules to communicate with structured data types by allowing each module to decide how to map it to and from its linear memory (and in future the runtime GC heap)

In your case you could be able to define WIT interfaces for your go types and have your compiler of choice use it to generate all the relevant glue code


This is the truth, and it's not really much better in non-GCed languages either. (In reality my impression is the GCed wasm side runtimes are even worse).

Some of the least fun JavaScript I have ever written involved manually cleaning up pointers that in C++ would be caught by destructors triggering when the variable falls out of scope. It was enough that my recollections of JNI were more tolerable. (Including for go, on Android, curiously).

Then once you get through it you discover there is some serious per-call overhead, so those structs start growing and growing to avoid as many calls as possible.

I too want wasm to be decent, but to date it is just annoying.


Was this dealing with DOM nodes and older IE versions by chance? That was probably the single biggest reason to wrap all DOM manipulation with JQuery in that it did a decent job of tracking and cleanup for you. IIRC, a lot of the issues came from the DOM and JS being in separate COM areas and the bridge not really tracking connections for both sides.


I need to pass all the user input events to a game engine, and get back the results into the webgl JS runtime side renderer. (The games at https://www.luduxia.com/ )


That would be more of a library than a WASM spec thing, no? I wrote a code generator that does this well for some internal use-cases.


This is exactly why I say WebGL/WebGPU are much better for perfomance code on the browser than dealing with WebAssembly tooling.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: