Seems like there are some trademark issues with just calling this SQLite.
It's cznic/sqlite in Go-land; this is just a quirk of HN titling.
A CGo-free port of SQLite/SQLite3
31–39 of 39 posts
Re: A CGo-free port of SQLite/SQLite3
#32The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
The biggest reason you'd want a cgo-free sqlite is if you're cross-compiling; for instance, from your macOS dev laptop to an x64 dev server.
Re: A CGo-free port of SQLite/SQLite3
#33Seems like there are some trademark issues with just calling this SQLite.
It's cznic/sqlite in Go-land; this is just a quirk of HN titling.
A quirk of this submitter's choice? We've seen it several times before without the trademark violation:
2023: Go port of SQLite without CGo (255 points, 118 comments) https://news.ycombinator.com/item?id=35488980
2020: Cznic/sqlite: Sqlite in pure Golang (no CGO) (6 points, not interesting for discussion.. this project is old) https://news.ycombinator.com/item?id=24358826
(7 other similar submissions)
Re: A CGo-free port of SQLite/SQLite3
#34Earlier quoted context omitted.
It's cznic/sqlite in Go-land; this is just a quirk of HN titling.
A quirk of this submitter's choice? We've seen it several times before without the trademark violation: 2023: Go port of SQLite without CGo (255 points, 118 comments) https://news.ycombinator.com/item?id=35488980 2020: Cznic/sqlite: Sqlite in pure Golang (no CGO) (6 points, not interesting for discussion.. this project is old) https://news.ycombinator.com/item?id=24358826 (7 other similar submissions)
I don't care, I just wrote to clarify the project, in the Go community, isn't called "sqlite". That wouldn't make sense; there are multiple (pin-compatible) sqlite interfaces for Go.
Re: A CGo-free port of SQLite/SQLite3
#35The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
If your codebase is pure golang it’s trivial to cross compile for different OSs (aside from binary signing on macOS). If you add some kind of C code you have to jump through a bunch of hoops to get a binary. Funny enough, I was looking for this exact project for that reason last week.
Re: A CGo-free port of SQLite/SQLite3
#36[flagged]
Just use a real web browser or enable JS, it's not that hard buddy. "Why do you keep hitting yourself?"
Re: A CGo-free port of SQLite/SQLite3
#37The readme really lacks the answer to the "why" question. What's the use case, why should I prefer it over real sqlite?
The biggest reason you'd want a cgo-free sqlite is if you're cross-compiling; for instance, from your macOS dev laptop to an x64 dev server.
Exactly. Even though your m5 max laptop will run the x86 binary just fine, if you don't compile it for arm, your m5 max laptop drops most of its speed and only has the same performance as an x86 server ...
Re: A CGo-free port of SQLite/SQLite3
#38So is this a handmade port vs the translated port done by modernc?
It's machine translated with TLA, tested, and finished by adding a few extra pure go mechanisms (such as Go code-backed virtual tables)
Re: A CGo-free port of SQLite/SQLite3
#39This project seems to get shared every month or so. It's really sad that HN's signal to noise has fallen this hard... While I continue to have it in my feed, I'm more and more opening up Reddit since it just feels more robust now adays.