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

A CGo-free port of SQLite/SQLite3

gitlab.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: A CGo-free port of SQLite/SQLite3

#11

Post by ameliaquining »

usrnm wrote: post #9

The 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, etc.) only hold if the entire build is pure Go.

Re: A CGo-free port of SQLite/SQLite3

#13

Post by usrnm »

blubber wrote: post #10
usrnm wrote: post #9

The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?

Because it's cgo-free maybe?

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

Re: A CGo-free port of SQLite/SQLite3

#14

Post by zzo38computer »

ftgffsdddr wrote: post #7

[flagged]

I agree that it would be better to not require JavaScripts. (But, I think it can be helpful to have mirrors on other services as well, for this and other reasons.)

However, there are some work arounds to some situations. Git could (presumably) still be used, if you have that (although you might not want the entire repository and only some files, so that is a possible issue with this). If you have a URL of a specific file that you can change "blob" to "raw" in the URL to access the raw file (this works on other services as well and is not specific to Gitlab). For commits, you can add ".patch" or ".diff" on the end of the URL (this also is not specific to Gitlab).

Re: A CGo-free port of SQLite/SQLite3

#15

Post by figmert »

usrnm wrote: post #13
blubber wrote: post #10

Earlier quoted context omitted.

Because it's cgo-free maybe?

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

Absolutely not. Maybe runtime overheads are minimal, but builds are so much harder to do. And yes, you need to figure it out maybe once, but it is still a lot more effort than just pulling in a new dependency. Now repeat that same effort for every new application, vs pulling that into every new application.

Re: A CGo-free port of SQLite/SQLite3

#16

Post by anupcshan »

usrnm wrote: post #13
blubber wrote: post #10

Earlier quoted context omitted.

Because it's cgo-free maybe?

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

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.

Re: A CGo-free port of SQLite/SQLite3

#17

Post by raggi »

usrnm wrote: post #13
blubber wrote: post #10

Earlier quoted context omitted.

Because it's cgo-free maybe?

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

that’s really not true when the database is all in memory, statements are prepared, and so on.

but the overheads also stack up, the database/sql api is fairly allocation heavy too unless you do a lot of work and that friction increases quite a bit with the ffi boundary.

this is not to suggest “modernc is faster” - it’s not for a lot a workloads.

there are opportunities for optimization all over both approaches.

Re: A CGo-free port of SQLite/SQLite3

#18

Post by usrnm »

anupcshan wrote: post #16
usrnm wrote: post #13

Earlier quoted context omitted.

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

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

Re: A CGo-free port of SQLite/SQLite3

#19

Post by dizhn »

anupcshan wrote: post #16
usrnm wrote: post #13

Earlier quoted context omitted.

Cgo overhead is trivial compared to what's happening inside a database engine, totally not worth it

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.

Re: A CGo-free port of SQLite/SQLite3

#20

Post by Ferret7446 »

usrnm wrote: post #18
anupcshan wrote: post #16

Earlier 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

Depends on what you mean by "most". The cross compile story for Go is far superior to C for the platforms it supports.
Post reply on HN