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 popular storage technologies couldn't be accessed with pure Go.
Other databases (Postgres, MySQL, etc.) already have clients written in pure Go. SQLite does not have a client/server architecture, so a pure Go version of it requires porting (or transpiling) the entire engine to Go.
> you think they’re gonna pay for what they’re not gonna use
This is it. They have internal datastores that they use for nearly everything. They might be using SQLite somewhere for something, but I really doubt this would even land near the bottom of their priority list.
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.
Google's practice is that every service they build is built that way that it can scale to millions of users. On servers i don't think they would use sqlite unlike in android. If i build stuff i usually start with sqlite.
Always seemed silly that one of the most popular storage technologies couldn't be accessed with pure Go.