[flagged]
[flagged]
No it doesn't.
A CGo-free port of SQLite/SQLite3
21–30 of 39 posts
Re: A CGo-free port of SQLite/SQLite3
#22The 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,…
So because of Go's design mistakes.
Re: A CGo-free port of SQLite/SQLite3
#23Earlier quoted context omitted.
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.
Static builds cannot have cgo too if I am not mistaken.
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:
-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.
Re: A CGo-free port of SQLite/SQLite3
#24Earlier quoted context omitted.
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,…
So because of Go's design mistakes.
Compared to what? Other languages AFAIK don't offer those properties at all, except I guess Zig.
Re: A CGo-free port of SQLite/SQLite3
#25[flagged]
[deleted]
Re: A CGo-free port of SQLite/SQLite3
#26Earlier quoted context omitted.
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.
I'm pretty sure that C is a much better choice if you really care about binaries that run on most devices
This project is for using Sqlite from Go code. It is not a general purpose replacement.
Re: A CGo-free port of SQLite/SQLite3
#27I 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!
> 3. github.com/mordernc-org/sqlite is the read-only mirror of the primary repo
Typo, should be: github.com/modernc-org/sqlite
Re: A CGo-free port of SQLite/SQLite3
#28There's also my take on this [1], which does machine translation from C to Go via Wasm using [2].
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.
Re: A CGo-free port of SQLite/SQLite3
#29Seems 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
SEQUEL. It was a play on QUEL [https://en.wikipedia.org/wiki/QUEL_query_languages].
Re: A CGo-free port of SQLite/SQLite3
#30Earlier quoted context omitted.
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,…
So because of Go's design mistakes.
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.