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.
Right. But you have to do it only once, or you can download a pre-built library from https://github.com/cvilsmeier/sqinn/releases (windows/amd64 or linux/amd64)
The main go compilation must work in all sorts of environments: dev computers, CI runners.. it should be quick and automated to keep development fast. It should be easy, so everyone on your team can do this.
The assistant process is basically built once and then never changes, you just need to keep a binary somewhere (and they seem to be <1MB so you can check them into git directly). So a single person somewhere has to figure how to do a C build once, and everyone else can benefit. Have your someone ssh into CI runner directly and install gcc. Spend a day installing compiler and messing with Makefiles on exotic OS. You only do it once and you are good forever (or until you want to bump sqlite version)
> It is used in programming environments that do not allow calling C API functions.
Also I guess which one is easier will be subjective. The steps are sorta similar:
Step 1) install sqlite or squinn on the base system (the latter might be harder)
Step 2) if sqllite use cgo, if squinn just use go (the former might be harder but more performant)
I'm actually surprised by how readable this came out; props to the Go->C compiler author. But you can guess that pushing this sort of thing through the Go compiler is going to cause some slowdowns due to sheer paradigm mismatch: https://gitlab.com/cznic/sqlite/-/blob/master/lib/sqlite_lin...
As soon as you or a library touches cgo, you have to deal with finding and setting up C cross-compilation tooling for your target(s), dynamic linking details, tons of stuff that may have nothing to do with your code or be an area you're an expert in as a Go developer.
You'll need to use the sqlite3_nolock build tag; concurrent writes will quickly corrupt your database. SetMaxOpenConns(1) is your friend.
But it should work. I'm interested if it doesn't. Feedback appreciated.
