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

Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

github.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#31

Post by eatonphil »

tedunangst wrote: post #23
eatonphil wrote: post #2

If you really want to use SQLite without anything that isn't Go (since this project involves forking and communicating with a non-Go SQLite in a separate process over pipes), there's a Go translation of SQLite's C source. :) https://gitlab.com/cznic/sqlite https://datastation.multiprocess.io/blog/2022-05-12-sqlite-i...

The logic of easy cross compiles doesn't really hold up for go translated SQLite. It depends on a huge pile of per platform support code, of varying quality. If you're only going to target known working platforms, may as well use cgo and a known working cross compiler.

I don't think cznic's argument is about cross compiling but just being able to avoid cgo. Since some people really don't like cgo.

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#32

Post by tedunangst »

eatonphil wrote: post #31
tedunangst wrote: post #23

Earlier quoted context omitted.

The logic of easy cross compiles doesn't really hold up for go translated SQLite. It depends on a huge pile of per platform support code, of varying quality. If you're only going to target known working platforms, may as well use cgo and a known working cross compiler.

I don't think cznic's argument is about cross compiling but just being able to avoid cgo. Since some people really don't like cgo.

I don't think I understand what the argument for that is, because I've only ever heard it articulated as "cgo isn't go" which doesn't really convey much information.

Is this go? https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go?...

I mean technically I suppose it is code that conforms to the go language grammar, but I'm not sure why a language purist would accept this.

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#33

Post by llimllib »

ncruces wrote: post #24
irusensei wrote: post #20

Earlier quoted context omitted.

Golang works on Plan9. It can even bootstrap itself. A few months ago I was trying to setup some server software on 9Front for giggles and while most stuff worked I couldn't past the Sqlite CGO dependencies.

If you still have that itch to scratch, you can try: https://github.com/ncruces/go-sqlite3 You'll need to use the sqlite3_nolock build tag; concurrent writes will quickly corrupt your database. SetMaxOpenConns(1) is your friend. But it should work. I'm interested if it doesn't. Feedback appreciated.

Very neat! Any idea how its performance compares to the modernc port?

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#34

Post by arp242 »

tedunangst wrote: post #32
eatonphil wrote: post #31

Earlier quoted context omitted.

I don't think cznic's argument is about cross compiling but just being able to avoid cgo. Since some people really don't like cgo.

I don't think I understand what the argument for that is, because I've only ever heard it articulated as "cgo isn't go" which doesn't really convey much information. Is this go? https://gitlab.com/cznic/libc/-/blob/master/libc_openbsd.go?... I mean technically I suppose it is code that conforms to the go language grammar, but I'm not sure why a language purist would accept this.

"cgo isn't go" is repeated as a point of religion by some.

That said, I have a bunch of QEMU VMs just to compile cgo to platforms like OpenBSD, illumos, macOS, Windows, etc.

OpenBSD and such aren't that much of a hassle because it performs pretty well and these systems do what I tell them to do, unlike macOS and especially Windows, which are much more annoying and slower because they seem to spend most of their time running searching indexers, virus scanners, updaters, and who knows what, and then maybe perhaps, if the laptop is held at the right angle, and if it so behoves, also decides to spend some CPU cycles to my compiler.

Either way, the pain is real, at least for me. Although, yeah, that obviously isn't a solution.

In general I'm wary of write/translate from langX to langY. At a previous job another team was rewriting ColdFusion code to Go. "ColdFusion with Go syntax" was certainly a creative and novel use of the Go language. Translating from one language to another always seems hard because your brain gets "primed" by the source language, or something, and not all concepts necessarily map all that well in the first place – I have the same translating text, which I've generally found surprisingly hard.

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#35

Post by ComputerGuru »

parhamn wrote: post #12
ComputerGuru wrote: post #10

Earlier quoted context omitted.

But compiling the non-go assistant process is not going to be any easier than cgo, right?

Well its a different access pattern. As the underlying library points out: > It is used in programming environments that do not allow calling C API functions. Also I guess which one is easier will be subjective. The steps are sorta similar: Step 1) install sqlite or squinn on the base system (the latter might be harder) Step 2) if sqllite use cgo, if squinn just use go (the former might be harder but more performant)

Which programming environments that do not allow calling C API functions also let you build/ship arbitrary C executables, though? (Genuinely curious what scenarios this unlocks.)

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#37

Post by theamk »

ComputerGuru wrote: post #10
parhamn wrote: post #8

Earlier quoted context omitted.

> Just the usual cgo performance overhead? No, the performance is certainly orders of magnitude faster than serializing over std streams on a subprocess (c ffi calls in cgo are 10s of nanoseconds). But one of the big draws of golang is the write-once-compile-anywhere toolchain and calls cgo makes that harder.

But compiling the non-go assistant process is not going to be any easier than cgo, right?

I don't think so.

The main go compilation must work in all sorts of environments: dev computers, CI runners.. it should be quick and automated to keep development fast. It should be easy, so everyone on your team can do this.

The assistant process is basically built once and then never changes, you just need to keep a binary somewhere (and they seem to be <1MB so you can check them into git directly). So a single person somewhere has to figure how to do a C build once, and everyone else can benefit. Have your someone ssh into CI runner directly and install gcc. Spend a day installing compiler and messing with Makefiles on exotic OS. You only do it once and you are good forever (or until you want to bump sqlite version)

Re: Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go

#39

Post by oefrha »

infogulch wrote: post #6
scosman wrote: post #4

Earlier quoted context omitted.

What’s the case against cgo for SQLite? Just the usual cgo performance overhead? It seems like a pretty good cgo use case: a decent amount of work, which is typically slow enough that cgo overhead isn’t perf critical (because DB usually means disk reads), a super robust and well tested C library with a super well maintained cgo wrapper (mattn).

mattn's sqlite3 is probably the most ideal use case for cgo imaginable. But it can still be annoying to set up cgo to build across many platforms. I think Go should just pull a Zig and just embed a full blown C compiler into go build.

Pulling a zig isn't going to solve all problems, as the zig cross compiler itself runs into problems fairly often. I already use CC='zig cc -target x86_64-linux-musl' (or whatever the target is) with cgo to cross-compile mattn/go-sqlite3, and relatively recently it simply stopped working[1] and a workaround had to do be added to about every single project of mine using SQLite through cgo.

I also once tried to figure out a way to cross compile mattn/go-sqlite3 to 32bit Windows with zig, and failed.

The best way to make cross compiling painless is to not use cgo at all. Which is why I use modernc/sqlite whenever possible now.

Btw, bundling a C compiler is also much harder when you don't build on top of LLVM.

[1] https://github.com/mattn/go-sqlite3/issues/1164

Post reply on HN