- SQLite is coded in C, so performance and weight are going to be equal or better than any other reimplementation.
- Having one code base means no compatibility issue between implementations
- Also SQLite's codebase is so heavily tested and its track record is so good that I really don't see the point.
* We have a sandboxed Javascript runtime inside of the JVM that can only do restricted work. IT would be nice to be able to use something like a SQLite file to deliver configuration to this Javascript runtime
* There are environments where you cannot install any native code -- like serverless providers that require your software to be pure Java / Javascript / Python
* Cross-language debugging can be very difficult when something goes wrong
* Erlang's FFI model is either "blocking and fast" (it runs the FFI call inline, and halts preemptive multitasking), or "slow and safe" (dirty NIFs, where it runs FFI calls on a dedicated thread.) This can get really ugly, really quickly.
Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer.
CGo-free SQLite for Linux: https://godoc.org/modernc.org/sqlite