Our platform support is limited by LLVM though, this is a good reason for sure.
Our platform support is limited by LLVM though, this is a good reason for sure.
Regardless, those are called "landing pads", and you can compile with an option to turn them off. Many do.
You have a hell of a lot of control over its performance and behaviour. Are there instances where you found that wasn't the case?
As far as the understanding of C goes, I can agree with that. But we are discussing rewriting sqlite in something else after all.
Seeing as Go was suggested above (which is also garbage collected), I figured I would mention Nim too.
Love to hear what those are and what language you would consider developing SQLite in.
But, I tried working in Nim without GC and out turned out to be a bigger hassle than I expected it to be. GC was supposed to be ref counted and now they're doing memory regions? There is also a -gc:stack which I'm not sure if it works the way like in C++. Then there is the pointer free paradigm. Don't get me wrong, I'm very optimistic about Nim and would be great if it really replaces C. But I feel like it's doing too many things at once.
I personally feel like Nim dev team should stop adding new features every release and work on releasing a solid 1.0.