libddwaf VS wazero

Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove a couple of GNUisms.

For C++ we were faced with some issues, so the process we ended up with is:

- build musl, install it in some location

- inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use

- build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot

- build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in

- for a dynamic lib, remove dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++)

- for an executable binary instead of a lib, dynamic reference would instead need to be altered so that it works for both

It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software)

https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...

While I'm sure Goja is great for just JavaScript, using something like wazero allows your app to support more languages (anything that compiles to WASM) while keeping the benefits of CGO.

https://wazero.io/

I've used Wazero myself on C++ -> WASM code but I'm sure you could use Emscripten or something to compile JavaScript to WASM.

and for reference see how it's done in wazero https://github.com/tetratelabs/wazero/blob/c397a402ad17e495a...

https://github.com/tetratelabs/wazero/releases/tag/v1.7.0

This includes the final release of the new optimizing compiler, which is a big improvement over the previous one.

The new version also adds experimental support for threads and snapshot/restore (setjmp/longjmp).

This is already being used by go-pgquery, all will mean that sqlc won't need to ship to almost copies of wazero (these features had been implemented on a friendly fork, and have now been up-streamed).

> Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero

Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing!

--

1: https://github.com/tetratelabs/wazero/blob/main/examples/bas...

2: https://natsbyexample.com/examples/messaging/pub-sub/go

It is slower.

The WASM runtime wazero [1] uses a compiler on amd64 and arm64 (on Linux, macOS, Windows, and FreeBSD), but the current compiler is very fast (at compiling), but very naive (generates less than optimal code).

An optimizing compiler is currently being developed, and should be released in the coming months. I'm optimistic that this compiler will cover the performance gap between WASM and modernc.

[1]: https://wazero.io

I am a fan of the Jacobin project! For your uses, you may also want to consider wazero [1], a pure-go WebAssembly runtime. Full disclosure: I am on the team :)

[1]: https://wazero.io/