Earlier quoted context omitted.
I cross compile mattn/go-sqlite3 a lot. It's about the easiest cgo project to cross compile since it has no external dependencies. Just use zig as your c compiler and it all just works.
Do you have any links for using Zig for this?
I benchmarked six Go SQLite drivers
31–40 of 64 posts
Re: I benchmarked six Go SQLite drivers
#32In my personal opinion and usage, the performance doesn't matter. Only one driver is written in pure go, and can be easily statically compiled and/or cross-compiled. > modernc, modernc.org/sqlite, a pure Go solution. This is a newer library, based on the SQLite C code re-written in Go. Unless I'm mistaken, this is not a re-write in Go. This is a transpilation of the the SQLite C library into go, using https://gitlab.…
Sqlite developers go to very great lengths making sure their software works reliably. You can't just introduce some transpiler in-between and expect that it'll work. It's a different software and it should not even be called sqlite IMO. The only proper way to use sqlite is to use FFI.
Re: I benchmarked six Go SQLite drivers
#33Re: I benchmarked six Go SQLite drivers
#34Earlier quoted context omitted.
I cross compile mattn/go-sqlite3 a lot. It's about the easiest cgo project to cross compile since it has no external dependencies. Just use zig as your c compiler and it all just works.
Do you have any links for using Zig for this?
Re: I benchmarked six Go SQLite drivers
#35Earlier quoted context omitted.
Maybe because Go devs are more allergic to 'non-Go' solutions that Java devs are to 'non-Java' solutions? (Explain: Java's xerial driver is a DLL/SO wrapped in a Java library)
Also because there's a mismatch between goroutines and C threads as described here https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... while Java threads can map 1:1 to C threads.
Re: I benchmarked six Go SQLite drivers
#36Earlier quoted context omitted.
Sqlite developers go to very great lengths making sure their software works reliably. You can't just introduce some transpiler in-between and expect that it'll work. It's a different software and it should not even be called sqlite IMO. The only proper way to use sqlite is to use FFI.
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...
Re: I benchmarked six Go SQLite drivers
#37Re: I benchmarked six Go SQLite drivers
#38[flagged]
Re: I benchmarked six Go SQLite drivers
#39[flagged]
Did you run the Go benchmarks on the same laptop to compare?
Re: I benchmarked six Go SQLite drivers
#40In my personal opinion and usage, the performance doesn't matter. Only one driver is written in pure go, and can be easily statically compiled and/or cross-compiled. > modernc, modernc.org/sqlite, a pure Go solution. This is a newer library, based on the SQLite C code re-written in Go. Unless I'm mistaken, this is not a re-write in Go. This is a transpilation of the the SQLite C library into go, using https://gitlab.…
> Only one driver is written in pure go, and can be easily statically compiled and/or cross-compiled. Which one do you mean? The WASM one? It includes WASM, it needs to be compiled too. Ah github.com/cvilsmeier/sqinn-go. Which... is made by the same person that made this benchmark...? edit: and that requires some random binary to be pre-installed...? Which is in C anyway? https://github.com/cvilsmeier/sqinn-go https:…