41–50 of 238 posts
Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!
Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!
Earlier quoted context omitted.
I do see a need for multiple implementations of SQLite3. First there's the need for multiple implementations for the reasons given by the LibSQL folks, second there's the need for a memory-safe language implementation of SQLite3, and third there's the need for a native language implementation for languages whose runtimes really want not to have C involved (e.g., Go).
The fact that there's no alternative implementation of SQLite also seems to play a part in preventing standardization of WebSQL. https://www.w3.org/TR/webdatabase/ "The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path."
I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?
The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.
The reason is obvious, of course: it has less features, and doing nothing is always faster than doing something.
Once it's feature complete, then meaningful comparisons can be made. For now, it's puffery.
Are there any plans for the python bindings to support an async interface?
Earlier quoted context omitted.
The fact that there's no alternative implementation of SQLite also seems to play a part in preventing standardization of WebSQL. https://www.w3.org/TR/webdatabase/ "The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path."
I was completely unaware of that! How old is that document? I should reach out.
Earlier quoted context omitted.
The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.
> Executing cargo bench on Limbo’s main directory, we can compare SQLite running SELECT * FROM users LIMIT 1 (620ns on my Macbook Air M2), with Limbo executing the same query (506ns), which is 20% faster. Faster on a single query, returning a single result, on a single computer. That's not how database performance should be measured or compared. In any case, the programming language should have little to no impact on…
It is to highlight that we already reached a good level of performance this early in the project.
Your claim about the programming language having no impact is just false, though. It's exactly what people said back in 2015 when we released Scylla. It was already false then, it is even more false now.
The main reason is that storage is so incredibly fast today, the CPU architecture (of which the language is a part) does make a lot of difference.
disclosure: I work here. I am happy to answer any questions tl;dr We are rewriting SQLite in Rust. It uses Asynchronous I/O, considers WASM as first class, and has Deterministic Simulation Testing support from the beginning. source: https://github.com/tursodatabase/limbo