Hacker News Reader

Comment by galacticdessert | Hacker News Reader

Looks good! Just for my understanding, what would be the advantage of working with wasm binaries instead of, let's say, C external libraries or DLLs via ctypes?

I can think of: 1. Portability of the wasm binaries

Is easier interoperability between data types an advantage as well? Ctypes can be a nightmare when passing around structs and pointers (and pointers of pointers, etc.)

View on HN

I have an actual real-world use case for this :)

Shader-cross-compilation for 3D frameworks:

https://floooh.github.io/2017/05/15/oryol-spirv.html

I'm hooking python scripts as custom-build-jobs into C/C++ projects which (for instance) takes care of compiling GLSL shader code into HLSL (D3D), MSL (Metal) and various GLSL versions (for GLES2, GLES3 and desktop GL).

Khronos provides C++ projects which help with this stuff:

https://github.com/KhronosGroup/glslang

https://github.com/KhronosGroup/SPIRV-Cross

So I'm using Python to hook my custom build jobs into the C/C++ build system (via cmake), but I still need to invoke native command line tools (or DLLs) which wrap around those Khronos libraries. Currently this means building (at least) 3 executables for Windows, macOS and Linux, and "distribute" those precompiled exes with my python code.

It looks like with this python+wasmer solution, I can instead compile the Khronos libraries into WASM modules, and the result runs "anywhere" where wasmer runs (e.g. also Raspberry Pi, BSDs etc...).

That's really cool stuff :)

There's also sandboxing. You shouldn't load untrusted DLL, but loading potentially untrusted WASM is a design goal of WebAssembly.

Portability might also bring along with it easier reproducible builds? Right now I believe if you use wheels, you basically have to trust that the distributed binary matches the source code. I saw a case where a package was taken over by a new maintainer who released wheels for an existing source release, and everyone basically shrugged and said, eh, this is probably fine, because there was no easy way to check. It sounds much easier to build an automated system that could check if wasmer-based packages are faithfully compiled from source, because there's only one compile target.

Sandboxing also sounds valuable, as mentioned by a sibling. I'm thinking of projects like imagemagick that run all kinds of untrusted input through all kinds of processing. It would be nice if there was a simple default way to write data processing libraries the way djb would write them.[1]

[1] https://cr.yp.to/qmail/qmailsec-20071101.pdf

My first impression is that the goal of this project is to run binaries that were likely built for other purposes like the web, not that they actually think that making libraries into webasm and running them into python has any particular advantages vs other options that already exist

Reply on news.ycombinator.com