I don't care, I just wrote to clarify the project, in the Go community, isn't called "sqlite". That wouldn't make sense; there are multiple (pin-compatible) sqlite interfaces for Go.
The "port" terminology is misleading; this is real SQLite, compiled from C to Go using 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.
No. 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.
It'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.
The 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:
Absolutely 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.
that’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.
I agree that it would be better to not require JavaScripts. (But, I think it can be helpful to have mirrors on other services as well, for this and other reasons.)
However, there are some work arounds to some situations. Git could (presumably) still be used, if you have that (although you might not want the entire repository and only some files, so that is a possible issue with this). If you have a URL of a specific file that you can change "blob" to "raw" in the URL to access the raw file (this works on other services as well and is not specific to Gitlab). For commits, you can add ".patch" or ".diff" on the end of the URL (this also is not specific to Gitlab).
1. gitlab.com/cznic/sqlite is the primary repo
2. github.com/cznic/sqlite was the github mirror but it moved
3. github.com/mordernc-org/sqlite is the read-only mirror of the primary repo
Cheers!
Typo, should be: github.com/modernc-org/sqlite
It's a somewhat less faithful translation, since I manually ported the VFS (SQLite OS abstraction layer).
OTOH, each SQLite connection is sandboxed (can't access/corrupt Go memory, or other SQLite connections). And it should run everywhere Go runs.
1: https://github.com/ncruces/go-sqlite3
2: https://github.com/ncruces/wasm2go
2023: Go port of SQLite without CGo (255 points, 118 comments) https://news.ycombinator.com/item?id=35488980
2020: Cznic/sqlite: Sqlite in pure Golang (no CGO) (6 points, not interesting for discussion.. this project is old) https://news.ycombinator.com/item?id=24358826
(7 other similar submissions)
-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.
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.
Would you please host it on a different forge, eg codeberg
However, there are some work arounds to some situations. Git could (presumably) still be used, if you have that (although you might not want the entire repository and only some files, so that is a possible issue with this). If you have a URL of a specific file that you can change "blob" to "raw" in the URL to access the raw file (this works on other services as well and is not specific to Gitlab). For commits, you can add ".patch" or ".diff" on the end of the URL (this also is not specific to Gitlab).
Would you please host it on a different forge that doesn't require a web browser?
Would you please post this on a different discussion forum?