purego VS wazero

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Maybe interesting for you: https://github.com/ebitengine/purego

most X11 functionality can be accessed via xgb|xgbutil (jezek has a current fork). nucular makes use of it via shiny. OpenGL and such libraries can be assumed to exist on those systems, so directly calling those c libraries without cgo is a possibility. Ebiten is currently working on it: purego.

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego

https://github.com/ebitengine/purego Instead of Go using C toolchain, purego bypass it for already (should I say compiled or object-compiled)

You could use https://github.com/ebitengine/purego which would not require a C compiler to build

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/

No longer does Wasm/WASI need JS host! There are many spec-compliant runtimes built for environments from tiny embedded systems up to beefy arm/x86 racks:

- https://github.com/bytecodealliance/wasm-micro-runtime

- https://github.com/bytecodealliance/wasmtime

- https://github.com/wasmerio/wasmer

- https://github.com/tetratelabs/wazero

- https://github.com/extism/extism (disclaimer, my company's project - makes wasm easily embeddable into 16+ programming languages!)

full disclosure: I don't work on it, but the devs are committers/contributors to https://wazero.io (I am a wazero committer) :)