[daenney]

In the specific case of SQLite, you can use it through WASM now [1]. It uses the dependency and Cgo-free Wazero runtime.

Performance so far has been better than the modernc transpile and it’s probably sufficient for a lot of use cases.

[1] https://github.com/ncruces/go-sqlite3

[_lvbh]

Why not https://pkg.go.dev/modernc.org/sqlite

[daenney]

The WASM solution doesn’t rely on a custom libc or transpiler to convert C code to Go. The transpile is an amazing feat of engineering, but it’s hard to debug.

I can wrap my head around the small amount of wrapping the go-sqlite3 WASM library does. If I had to I can maintain that should the maintainer lose interest. I can’t say the same for the modernc transpile. You can also apply the WASM trick to other libraries with much less effort.

And as noted, it seems to be performing better. As the wasm runtime improves it should pull further ahead.

[kyrra]

Performance is likely part of it. The WASM solution looks faster than modernc: https://github.com/cvilsmeier/go-sqlite-bench

[ncruces]

Author here.

Faster was a by product. Maintainability was the goal.

API coverage, ergonomics, extensibility all rank higher in my book than performance.

An example I'd like to cite is sqlite-vec. Alex was able to build a Cgo-free version of it, on his own, which works fine with my bindings. This would be much harder to do with modernc.

https://github.com/asg017/sqlite-vec-go-bindings

I'm also adding support for building off the bedrock branch (begin concurrent, wal2). You just build the branch with wasi-sdk, then embed the resulting blob.

[0xjnml]

> This would be much harder to do with modernc.

https://go.dev/play/p/IztwH9Jl68i