wasm2go

Shameless plug: if you value Go, and CGO_ENABLED=0, and SQLite, and are worried about C in a web server and RCEs, may I interest you in my SQLite driver? https://github.com/ncruces/go-sqlite3 I just wrote up the security goals of the tool I use to translate C to Go: https://github.com/ncruces/wasm2go/blob/main/SECURITY.md I obviously can't make any promises, as it's just a personal pet project, but those are the goals, and they do catch memory corruption bugs in practice: https://sqlite.org/bugs/forumpost/543f94984b

Thanks for the link. Article makes it look like nothing happened in the embed/low-memory/single-threaded malloc space in decades since Doug Lea's malloc. I just implemented TLSF for my minimal Wasm libc: fragmentation is just as good, performance is a lot more consistent (and on average better), for a significant reduction in code size. http://www.gii.upv.es/tlsf/index.html https://github.com/ncruces/wasm2go/blob/main/libc-gen/c/mall...

Thanks for the kind words! Added you to my users page a couple days ago, hope you don't mind: https://github.com/ncruces/wasm2go/blob/main/USERS.md

Curious where my wasm2go would stand compared to wazero. I should test it myself. :) https://github.com/ncruces/wasm2go

I wrote this bump malloc that I use for very short lived Wasm modules: https://github.com/ncruces/wasm2go/blob/main/libc-gen/c/mall...

I wish I could've one shoted this 200 LoC PR: https://github.com/ncruces/wasm2go/pull/42/changes#diff-5181... I'd really like to know the prompt, because I did try and, this took me way too long to figure out.

I just spent a week reviewing this ~200 LoC PR: https://github.com/ncruces/wasm2go/pull/37 It was submitted by a seasoned user, who probably asked a frontier LLM. It still felt… wrong. I didn't understand it, and I wouldn't merge it without understanding it. I also suspected it was wrong, in a way that would cause issues in the future. So I reviewed it 4 different ways: (1) try to understand/improve it; (2) do it with better algorithms; (3) avoid it by fixing the issue upstream; (4) rewrite it from scratch probably just to match my brain. I expected either (2) or (3) would be the answer. (2) didn't work, rather it's the correct answer but I need to redo the project from scratch to use it; (3) I wanted really bad to work, but didn't. So I got to a blend of (1) and (4). I'm still not entirely convinced, but now I understand the issue/soluti

I built wasm2go, which I had meant to for some time but was a gargantuan task to get into a good enough shape to test if it was a good idea. I think it was (a good idea), and AI made it easier for sure. https://github.com/ncruces/wasm2go

There's also my take on this [1], which does machine translation from C to Go via Wasm using [2]. It's a somewhat less faithful translation, since I manually ported the VFS (SQLite OS abstraction layer). OTOH, each SQLite connection is sandboxed (can't access/corrupt Go memory, or other SQLite connections). And it should run everywhere Go runs. 1: https://github.com/ncruces/go-sqlite3 2: https://github.com/ncruces/wasm2go

I don't know that there was an inflection point. I know that, over the past year, they definitely became useful to me as more than auto complete. My most recent pet project is a transpiler from Wasm to Go, and I find it incredibly impressive that recent models (I've used Sonnet, Opus and Gemini, far more successfully than GPT), they're able to just pick up the project and work at all these levels: - Go code that implements the transpiler (parsing Wasm, building an AST) - Go code that gets generated by serializing the AST to a .go file - Go code that manipulates the AST (to optimize it), and its effect on the generated code - Go code that's grafted to the generated code (to implement more advanced opcodes) and how to interact with it from the AST - C code that gets compiled to Wasm, then translated to Go, then called by Go - Go code that g

Adding support for the threads/atomics proposal to my Wasm to Go transpiler: https://github.com/ncruces/wasm2go Since I started it a couple of months ago, it's been used by me to transpile SQLite to Go, and by some other folks to transpile other C, C++, Zig and even Perl libraries to Go.

Not very deep. Go generates large Wasm modules, because it bundles its goroutine scheduler, garbage collector and standard library into the module. Translating that back to Go will give you a pretty big Go file. Go is "known" for being fast to compile, but that huge Go file will take (at least?) as long to compile as compiling the Go toolchain does. wasm2go is best used on moderately sized modules (like SQLite). Last I heard, the person who tried to translate Perl got a 80MB Go file that was taking them 20min to compile. https://github.com/ncruces/wasm2go/discussions/15

Shameless plug… compiling it to Go is a great option too: https://github.com/ncruces/wasm2go I've used it to translate SQLite (with a few extensions) and, that I know of, it's been used (to varying degrees of success) to translate the MARISA trie library (C++), libghostty (Zig), zlib, Perl, and QuickJS. More on-topic, I use a mix of an unevaluated expression stack and a stack-to-locals approach to translate Wasm.

Still working on improving wasm2go (a Wasm to Go "transpiler"): https://github.com/ncruces/wasm2go Already using it for my SQLite driver, and already in use by some a few other projects: https://github.com/topics/wasm2go

If you're using Go on GitHub (and doing stuff where this actually matters) adding this to your CI can be as simple as this: https://github.com/ncruces/wasm2go/blob/v0.3.0/.github/workf... On Linux it's really as simple as installing QEMU binfmt and doing: GOARCH=s390x go test