|
|
|
|
|
|
by jlubawy
2525 days ago
|
|
|
Serious question, why hasn't anyone rewritten it in Go? Been awhile since I've looked at it but C to Go doesn't seem that difficult to translate. Edit: just looked at the amalgamation again, it's huge... Still surprised no one has tried it yet that I know of. Pre-processor directives would probably make it even more difficult though. Edit2: and it already works so what's the point, other than an extremely challenging problem |
|
|
It's really not that hard. The code is clearly documented and everything works in roughly the same way. Easily achievable by a single developer in a few months.
Sqlite code is emulating classes with structs and methods (they're even called classes in the code). This it's pretty easy to translate into languages with reference and struct support.
Memory allocation is separated into an allocation provider, which is easy to implement in GC languages (just create the struct requested).
The parser and VM opcode file is tricky. The opcodes are parsed from comments in one big file. I'm not a fan of that. But once generated for a particular version, pretty easy to translate.
Testing is another can of worms. Translating the exact version of Tcl, too is the best course of action. This is required to run and pass the (hundreds of thousands of) base line tests. Other correctness tests (in sqlite because of branch coverage requirements for aircraft software) are harder to translate. The prerelease burn in test is also not publicly available.
Preprocessor directives are not used as macros. Rather they are used to enable features. In a port, you can for example choose to exclude WAL or specific optimizations. FTS can be left out if not needed. The different lock implementations can be deferred to the stdlib.
If you interested in the perf overhead, here's a small benchmark of a C# implementation I maintain:
https://drive.google.com/file/d/11Bgfh1WgEreDenosoEdWkYAOb6u...