points by daenney 1 year ago

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 1 year ago
  • kyrra 1 year ago

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

    • ncruces 1 year ago

      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.

  • daenney 1 year ago

    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.