3 ms·

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 tha

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 https://github.com/ncruces/go-sqlite3

_lvbh 2y ago
Why not https://pkg.go.dev/modernc.org/sqlite https://pkg.go.dev/modernc.org/sqlite
- kyrra 2y ago
  Performance is likely part of it. The WASM solution looks faster than modernc: https://github.com/cvilsmeier/go-sqlite-bench https://github.com/cvilsmeier/go-sqlite-bench
  - ncruces 2y 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 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 2y ago
      > This would be much harder to do with modernc. https://go.dev/play/p/IztwH9Jl68i https://go.dev/play/p/IztwH9Jl68i
- daenney 2y 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.

_lvbh 2y ago

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

kyrra 2y ago
Performance is likely part of it. The WASM solution looks faster than modernc: https://github.com/cvilsmeier/go-sqlite-bench https://github.com/cvilsmeier/go-sqlite-bench
- ncruces 2y 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 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 2y ago
    > This would be much harder to do with modernc. https://go.dev/play/p/IztwH9Jl68i https://go.dev/play/p/IztwH9Jl68i
daenney 2y 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.