Here lies the problem. I now need to instruct users that different build flags are required for different platforms. Whereas that problem doesn’t exist with the cgo bindings.
Plus I also have the additional risk that I’m using someone’s hobby project that, and I say this with the greatest of respect for yourself, might get abandoned tomorrow for all I know.
Cgo might have its issues but for sqlite3 it offers far better assurances than anything else available for Go at this point in time.
Given that sqlite3 is a supporting library rather than the differentiator of my project, I want to spend as little time as I have to supporting it. At this point in time, only the cgo library seems to offer that convenience (though if anyone else wants to maintain a fork of my project using a different sqlite library then I’m more than happy with that).
Good luck with your project though. Hopefully the Go community can rally around one of these native solutions so it gains enough traction to become the new de facto standard.
I could easily build on all platforms without tags… I just want to avoid accidental data corruption if users unwittingly access databases without proper synchronization.
The MVCC-WAL-VFS I'm designing now may potentially fix this, as the brokenness of POSIX advisory locks is more manageable there.
I'll definitely keep an eye on this project. And likewise, if you feel you reach a new stable milestone that addresses my concerns, do feel free to raise an issue on my projects Github page for me to switch away from cgo :)
Plus I also have the additional risk that I’m using someone’s hobby project that, and I say this with the greatest of respect for yourself, might get abandoned tomorrow for all I know.
Cgo might have its issues but for sqlite3 it offers far better assurances than anything else available for Go at this point in time.
Given that sqlite3 is a supporting library rather than the differentiator of my project, I want to spend as little time as I have to supporting it. At this point in time, only the cgo library seems to offer that convenience (though if anyone else wants to maintain a fork of my project using a different sqlite library then I’m more than happy with that).
Good luck with your project though. Hopefully the Go community can rally around one of these native solutions so it gains enough traction to become the new de facto standard.