What approach is used here? WebAssembly (or something similar)? I see a bunch of huge Go files with architecture names.
JFYI a Wasm approach here
Go port of SQLite without CGo
41–50 of 122 posts
Re: Go port of SQLite without CGo
#42If you cross-compile (which everybody using macOS to developer for Linux servers does), it's annoying to introduce SQLite to your project, because immediately the conventional `GOOS= GOARCH= go build` trick stops working. But, in case it's helpful, it's also really easy to set up a full cross-compiling environment, either with Zig or with Filippo's musl-cross: https://words.filippo.io/easy-windows-and-linux-cross-com…
Cross compiling with zig is so easy. For example I use sqlite in Go projects on arm. The incantation is just: export GOARCH=arm64 export CC=zig cc -target aarch64-linux-musl export CXX=zig cc -target aarch64-linux-musl
Cross compilation is always easy when there are no dependencies to the target platform SDKs. When it goes beyond basic libc stuff, then it is when the fun starts.
Re: Go port of SQLite without CGo
#43Earlier quoted context omitted.
What makes it slower?
It’s hard for Go to beat C in a straight benchmark - Go is garbage collected and allocations often have extra overhead due to the memory layout of interfaces.
It is a matter of skill, Go can do manual memory management and stack allocation just as well.
Re: Go port of SQLite without CGo
#44Earlier quoted context omitted.
It’s hard for Go to beat C in a straight benchmark - Go is garbage collected and allocations often have extra overhead due to the memory layout of interfaces.
In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.
Gccgo is the answer here.
Re: Go port of SQLite without CGo
#45If you cross-compile (which everybody using macOS to developer for Linux servers does), it's annoying to introduce SQLite to your project, because immediately the conventional `GOOS= GOARCH= go build` trick stops working. But, in case it's helpful, it's also really easy to set up a full cross-compiling environment, either with Zig or with Filippo's musl-cross: https://words.filippo.io/easy-windows-and-linux-cross-com…
Not really, unless you're talking about specific Go developers, and even there, that is what the CI/CD pipeline is for. No one should touch servers directly, unless for down tracking stuff or remote development, in which case, they also don't need to cross compile.
Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.
Re: Go port of SQLite without CGo
#46Why would you want to do this? SQLLITE is so stable. Why would you switch to some port that will be dead in a year?
The project converts the SQLite C code and has been kept very up to date, so it is far more than a one-off port. The reason is to avoid dealing with CGO in your project, which is necessary with other drivers such as mattn/go-sqlite3.
Re: Go port of SQLite without CGo
#47I've use this. Slightly slower, but for my use case that was fine (a small blog) and immeasurably better doing away with all the CGO hassle. Especially when I might cross compile to an Arm architecture, or some docker container that uses a different approach to the c libraries (like Alpine vs Ubuntu Server or whatever) it was always a hassle, and thats all gone away now. Always seemed silly that one of the most popul…
Pretty much any database is NOT written in Go, so what's the difference?
Also Bolt is pure go which is a highly performant KV store
Re: Go port of SQLite without CGo
#48Beware: This library seems to have bugs that cause it to break on some writes. Recently held an event that heavily used this library and it broke on us half way through, had to wipe the database and switch it back to the cgo version (the data inside was mostly ephemeral, which was quite a relief).
Re: Go port of SQLite without CGo
#49What’s the point of something like this instead of just using SQLite? Seriously, “foo but in bar!” is not exactly the sort of thing that solves real problems for most people.
This isn’t reinventing the wheel in another language. This is a SQLite driver/implementation that is an alternative to the main one which relies on CGO which is annoying for development in some cases. Making this pure go makes compilation easier.
Re: Go port of SQLite without CGo
#50What’s the point of something like this instead of just using SQLite? Seriously, “foo but in bar!” is not exactly the sort of thing that solves real problems for most people.
CGO is a real problem for many people. Due to how Go handles its async-by-default concurrency model, every call to an FFI library requires setting up a stack and marshaling data. It ends up being rather expensive. So the "without CGo" stuff is about retaining the fast performance people expect of these highly optimized C libraries.