> You can't just introduce some transpiler in-between and expect that it'll work

Obviously it "works" and they didn't "just" transpile it but spent quite a bit of effort on this. Whether it's free of bugs that are not present in SQLite is a different matter. And while it's not run against the SQLite proprietary tests, it does pass all of the TCL tests IIRC, which are quite comprehensive on their own, so there shouldn't be huge glaring bugs.

They run the whole testsuite on the transpiled code. I think.

But yeah it does give me a little shiver to think you are transpiling C code to go code, and the go-code is not really "pure go", but has a platform-dependent unsafe operations. Just look at the repo

https://gitlab.com/cznic/sqlite/-/tree/master/lib?ref_type=h...

My understanding is that the full test suite is actually proprietary and it's part of how sqlite is funded — the maintainers can provide better claims. There is a public test suite but it's a subset of what they do.

https://www.sqlite.org/testing.html

We use go-sqlite3 at work and have had a positive experience, with the benefit of having fewer system dependencies and a simpler build process.

If the transpiler is not breaking any defined behavior in C, there is no reason to believe it cannot be a perfectly reasonable solution. There is nothing inherently wrong with targeting another programming language when compiling code, it does not mean there is anything wrong or broken with the generated code or its semantics.

It is a less battle-tested C compiler, sure, but it's a C compiler. IMO, you can't argue that something shouldn't be called sqlite because it contains a transpiled copy of sqlite. To me this isn't really substantially different from transpiling sqlite to JS using Emscripten.