3 ms·
The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
by usrnm 4mo ago
The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
- blubber 4mo agoBecause it's cgo-free maybe?
- usrnm 4mo agoCgo overhead is trivial compared to what's happening inside a database engine, totally not worth it
- figmert 4mo agoAbsolutely not. Maybe runtime overheads are minimal, but builds are so much harder to do. And yes, you need to figure it out maybe once, but it is still a lot more effort than just pulling in a new dependency. Now repeat that same effort for every new application, vs pulling that into every new application.
- anupcshan 4mo agoIt's not just about overhead/performance. cgo-free means no need to set up a cross-compiler if targeting other devices. Just "go build" with the right GOARCH and GOOS will let you compile a binary that will run on most devices.
- usrnm 4mo agoI'm pretty sure that C is a much better choice if you really care about binaries that run on most devices
- Ferret7446 4mo agoDepends on what you mean by "most". The cross compile story for Go is far superior to C for the platforms it supports.
- anupcshan 4mo agoThis project is for using Sqlite from Go code. It is not a general purpose replacement.
- dizhn 4mo agoStatic builds cannot have cgo too if I am not mistaken.
- agwa 4mo agoThe following go flags let you build statically-linked cgo binaries, provided that all the C libraries that you're using support static linking and don't call the NSS functions in glibc: -tags netgo,osusergo -linkmode external -extldflags -static I regularly compile (cross-compile, even) static Go binaries that use the cgo sqlite package. But it's certainly a lot simpler if you can avoid cgo.
- raggi 4mo agothat’s really not true when the database is all in memory, statements are prepared, and so on. but the overheads also stack up, the database/sql api is fairly allocation heavy too unless you do a lot of work and that friction increases quite a bit with the ffi boundary. this is not to suggest “modernc is faster” - it’s not for a lot a workloads. there are opportunities for optimization all over both approaches.
- ameliaquining 4mo agoThe "port" terminology is misleading; this is real SQLite, compiled from C to Go using https://gitlab.com/cznic/ccgo/-/tree/master/v4 https://gitlab.com/cznic/ccgo/-/tree/master/v4 (by the same author; this library is its most widely used application). The use case is that a lot of Go codebases prefer to completely eschew FFI because a lot of the nice properties of Go's tooling and whatnot (cross-compilation is trivial, binaries are automatically static on Linux, etc.) only hold if the entire build is pure Go.
- ivanjermakov 4mo agoSo because of Go's design mistakes.
- ameliaquining 4mo agoCompared to what? Other languages AFAIK don't offer those properties at all, except I guess Zig.
- 10000truths 4mo agoNo. A mistake is unintentional. Go's rejection of a C runtime dependency is a deliberate trade off, and one that has served it well for its design goals.
- tptacek 4mo agoThe biggest reason you'd want a cgo-free sqlite is if you're cross-compiling; for instance, from your macOS dev laptop to an x64 dev server.
- spwa4 4mo agoExactly. Even though your m5 max laptop will run the x86 binary just fine, if you don't compile it for arm, your m5 max laptop drops most of its speed and only has the same performance as an x86 server ...
- 0x20cowboy 4mo agoIf your codebase is pure golang it’s trivial to cross compile for different OSs (aside from binary signing on macOS). If you add some kind of C code you have to jump through a bunch of hoops to get a binary. Funny enough, I was looking for this exact project for that reason last week.