https://gitlab.com/cznic/sqlite
https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...
It seems like a pretty good cgo use case: a decent amount of work, which is typically slow enough that cgo overhead isn’t perf critical (because DB usually means disk reads), a super robust and well tested C library with a super well maintained cgo wrapper (mattn).
No, the performance is certainly orders of magnitude faster than serializing over std streams on a subprocess (c ffi calls in cgo are 10s of nanoseconds).
But one of the big draws of golang is the write-once-compile-anywhere toolchain and calls cgo makes that harder.
I think Go should just pull a Zig and just embed a full blown C compiler into go build.
1: https://zig.news/kristoff/building-sqlite-with-cgo-for-every...
That's the elevator pitch (so far) for: https://github.com/ncruces/go-sqlite3/tree/main
But there's this if you wanna try: https://github.com/ebitengine/purego
That's exactly what I thought, too. But, to my own surprise, it's as fast as CGO solutions, in most cases even faster. You may check here: https://github.com/cvilsmeier/sqinn-go-bench
https://www.synopsys.com/blogs/software-security/unlicensed-...
I've been using cgo for accessing sqlite for ages, never ever had any trouble. cgo is not remotely as bad as what people might believe. give cgo a go, and you will realize that it saves your time, let you focus on your projects rather than non-senses like how to use stdin/stdout redirection to bypass cgo.
