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.
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.
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.
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).
I was confused a few weeks ago. Check out the go pkg: https://pkg.go.dev/modernc.org/sqlite
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!
Seems like there are some trademark issues with just calling this SQLite.
SQL would have been SEQL if not for trademark issues, the torch is passed
The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
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.
Because it's cgo-free maybe?
Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it
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.
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.
So is this a handmade port vs the translated port done by modernc?
modernc is the name of the GitHub fork (identical repo) of the same project. This is machine translated, not hand written.
Gitlab requires js
Would you please host it on a different forge, eg codeberg
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).
HackerNews requires js.
Would you please post this on a different discussion forum?
Codeberg requires html
Would you please host it on a different forge that doesn't require a web browser?