Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go port of SQLite without CGo

gitlab.com

Post reply on HN
Print view View original

31–40 of 122 posts

Re: Go port of SQLite without CGo

#31

Post by ikiris »

JustSomeNobody wrote: post #14
AdeptusAquinas wrote: post #12

I'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…

>Always seemed silly that one of the most popular storage technologies couldn't be accessed with pure Go. I don't know why Google didn't pay someone to do this or do it themselves. Surely they use Go and sqlite together.

Why would someone at google ever use sqlite?

Re: Go port of SQLite without CGo

#32

Post by badtuple »

djbusby wrote: post #24
collinvandyck76 wrote: post #23

Earlier quoted context omitted.

at segment we benchmarked https://github.com/segmentio/ctlstore against this driver. We saw about a 50% hit to read performance, so we didn't move forward with it, but the improvements in service build times were really appealing.

Really tho, how much is build time vs runtime? Maybe is just work small projects but I rarely care about build time. Am I missing something?

Honestly, on a non-toy project, build times with cgo are _brutal_. I agree with you usually, but when a build time on a beefy computer switches from under a second to >1min you notice it.

Linters and IDEs get slow when they check for errors, tests run slow, feedback drags, and all your workflows that took advantage of Go's fast compile times are now long enough that your flow and mental context disappear.

I'm way more lenient with other languages since the tooling and ecosystem are built around long build times. Your workflows compensate. But Go's tooling and ecosystem assume it compiles fast and treat things more like a scripting language. When that expectation is violated it hurts and everything feels like it's broken.

Re: Go port of SQLite without CGo

#33

Post by tomjakubowski »

ikiris wrote: post #31
JustSomeNobody wrote: post #14

Earlier quoted context omitted.

>Always seemed silly that one of the most popular storage technologies couldn't be accessed with pure Go. I don't know why Google didn't pay someone to do this or do it themselves. Surely they use Go and sqlite together.

Why would someone at google ever use sqlite?

Chrome and Android make heavy use of SQLite. Not that Golang is very relevant to those projects

Re: Go port of SQLite without CGo

#34

Post by lopkeny12ko »

ikiris wrote: post #31
JustSomeNobody wrote: post #14

Earlier quoted context omitted.

>Always seemed silly that one of the most popular storage technologies couldn't be accessed with pure Go. I don't know why Google didn't pay someone to do this or do it themselves. Surely they use Go and sqlite together.

Why would someone at google ever use sqlite?

Why wouldn't they? Are you implying that, over the course of decades of Google's existence and thousands of software projects, not once has there ever had the need for a lightweight SQL store that can be embedded with a server or CLI tool?

Your comment truly does SQLite a disservice. SQLite is probably one of the most impressive pieces of software to have ever graced this earth.

Re: Go port of SQLite without CGo

#36

Post by emodendroket »

eatonphil wrote: post #2

It's a really neat project. I did some simple benchmarks of it and it was between 10% slower to twice as slow. Which depending on your use case isn't that bad! https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...

I’d go so far as to say it’s completely acceptable for 90+% of use cases.

Re: Go port of SQLite without CGo

#39

Post by psanford »

tptacek wrote: post #8

If 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

Re: Go port of SQLite without CGo

#40

Post by pjmlp »

tptacek wrote: post #8

If 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.

Post reply on HN