Go port of SQLite without CGo • Hacker News Board

Re: Go port of SQLite without CGo

#51

Post by adastra22 » Sat, Apr 08, 2023, 5:46 AM UTC

ehhthing wrote: post #48

Beware: 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).

Yeah I would be very suspect about this library. Writing a transpiler that handles all aspects of the C spec correctly is hard enough, to say nothing of replicating stuff that is technically undefined behavior but known to work a certain way. C is not Go and Go is not C--simply rewriting syntax will not result in exactly the same behavior.

Re: Go port of SQLite without CGo

#52

Post by cerved » Sat, Apr 08, 2023, 5:57 AM UTC

DangitBobby wrote: post #45

pjmlp wrote: post #40

Earlier quoted context omitted.

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.

I mostly touch servers remotely

Re: Go port of SQLite without CGo

#53

Post by KingOfCoders » Sat, Apr 08, 2023, 5:58 AM UTC

How does this compare to https://github.com/glebarez/go-sqlite ?

Using that for https://www.octobench.com/ and I'm very happy.

Re: Go port of SQLite without CGo

#54

Post by jamietanna » Sat, Apr 08, 2023, 6:02 AM UTC

I've been using this for one of my personal projects (https://dmd.tanna.dev) to simplify the cross-compilation process and so far it's been very good.

When I noticed the SHA3 extension was missing (https://gitlab.com/cznic/sqlite/-/issues/139) it was noted it could be very easily patched client-side which is handy, as well as adding functionality into the core library to handle it.

Re: Go port of SQLite without CGo

#55

Post by blowski » Sat, Apr 08, 2023, 6:13 AM UTC

pjmlp wrote: post #40

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.

Everyone _should_ also have 100% test coverage, canary deployments, and local dev parity. Unfortunately, the real world gets in the way and means we don’t all work with optimal setups.

Re: Go port of SQLite without CGo

#56

Post by kaba0 » Sat, Apr 08, 2023, 6:14 AM UTC

cdogl wrote: post #5

philosopher1234 wrote: post #3

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

Also, Go barely optimizes code, that’s how it compiles as fast.

Re: Go port of SQLite without CGo

#57

Post by pjmlp » Sat, Apr 08, 2023, 6:20 AM UTC

DangitBobby wrote: post #45

pjmlp wrote: post #40

Earlier quoted context omitted.

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.

Sure, but then DevOps aren't doing their jobs.

No devs on production servers unless for tracking down issues, or servers configured for remote development.

Which in both cases, don't require cross compilation to start with.

Re: Go port of SQLite without CGo

#58

Post by mariusor » Sat, Apr 08, 2023, 6:33 AM UTC

KingOfCoders wrote: post #53

How does this compare to https://github.com/glebarez/go-sqlite ? Using that for https://www.octobench.com/ and I'm very happy.

It looks like your library is using some of the plumbing from the parent. I can't tell what benefit it adds on top of it because the parent is also compatible with the Go standard library sql/driver API.

Re: Go port of SQLite without CGo

#59

Post by pjmlp » Sat, Apr 08, 2023, 6:36 AM UTC

blowski wrote: post #55

pjmlp wrote: post #40

Earlier quoted context omitted.

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.

Everyone _should_ also have 100% test coverage, canary deployments, and local dev parity. Unfortunately, the real world gets in the way and means we don’t all work with optimal setups.

In that case, it starts by having a local environment that matches the OS of the servers.

Linux OEM vendors will appreciate it.

Re: Go port of SQLite without CGo

#60

Post by mariusor » Sat, Apr 08, 2023, 6:38 AM UTC

eschaton wrote: post #28

What’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.

What exactly do you think "sqlite" is? By the way you asked the question, it seems like you're assuming it's a separate database that you execute alongside your application, similarly to postgres/mariadb/etc. That's not the case though.