I think https://gitlab.com/cznic/sqlite has become pretty popular. It’s a pure go implementation
That is useless to sqlite itself, this exists only because of go's issues and is essentially unusable outside of the go ecosystem.
The only issue I see with cgo is that they decided to follow such path instead of a proper FFI declaration support like most languages.
Even Java is now having such capability thanks Project Panama.
E.g. the hugo project built with and without extended features. Build without and it’s all go, it compiles in the blink of an eye. The tooling in go, from a devops point of view, is surprisingly good. It’s not just compile speed.
Build with all the c deps and well you’re compiling more code so of course it’s going to be slower but it’s disproportionately so.
Issue’s cgo doesn’t just make the build more complex and more expensive (and yeets cross-compilation), it also makes programming way more difficult as go tooling doesn’t understand C and C tooling has no clue about Go (because non-standard calling conventions and insular tooling community and everything), and for all that cost you get little because the go/c call overhead is stupendous (still, though smaller than it used to be), and of course it locks up the scheduler (after a slice of the goroutine being blocked the go runtime will create a new one, but still…).