Dunno. Good luck to them, but I never saw a need to rewrite sqlite.
Most of us don't see the need to do something until after it is done.
Limbo: A complete rewrite of SQLite in Rust
31–40 of 238 posts
Re: Limbo: A complete rewrite of SQLite in Rust
#32Earlier 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…
I can’t trust benchmarks on code that isn’t feature complete. The missing functionality is never free.
Re: Limbo: A complete rewrite of SQLite in Rust
#33Are there any plans for the python bindings to support an async interface?
Re: Limbo: A complete rewrite of SQLite in Rust
#34Earlier quoted context omitted.
Related: https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn... C libraries aren't automatically the fastest option, there's a lot of C code which has stagnated on the performance front but is still widely used because it's battle tested and known to be robust by C standards.
There's still an element of truth in the idea that C is going to be faster by default. There's simply a much lower bar to writing fast (and unsafe) C. Fast Rust demands considerably more thoughtfulness from the programmer (at least for me).
> There's simply a much lower bar to writing fast (and unsafe) C.
That's kind of my point, writing a faster PNG decoder in C may be easier for you but convincing anyone to actually use it instead of the slower but proven safe-ish libpng would be an uphill battle. Trust in C code is extremely hard-won compared to Rust which uses little if any unsafe. The 'png' crate that Chrome is considering to replace libpng has no unsafe whatsoever and is still faster.
Re: Limbo: A complete rewrite of SQLite in Rust
#35When the initial SQLite3->LibSQL fork was announced I was pretty negative about it because SQLite3 has a wonderful, 100% branch coverage test suite that is proprietary , and so without access to that any fork would be bound to fail. However, if there's a big product behind the fork, and even better, a rewrite to a memory-safe language, then the fork begins to make a lot of sense. So, hats off to y'all for pulling thi…
Good luck for sure, but browsing their compatibility matrix, it looks like they are a LONG way off. By the looks of it, they have mostly read compatibility with little write capabilities (no alter table, for example).
That's fully in line with what they're announcing here. It's the announcement of a new project that has passed the prototyping stage, but one that has not reached the 1.0 stage.
Re: Limbo: A complete rewrite of SQLite in Rust
#36Given 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!
[flagged]
Re: Limbo: A complete rewrite of SQLite in Rust
#37Given 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!
While I agree with you on one level, that code rigidity and testing means that a port of SQLite is much more viable than most other C-based projects. And I'm intrigued by what this would enable, e.g. the WASM stuff the authors mention. It's not that it couldn't be done in C but it'll be easier for a wider range of contributors to do it in Rust.
Re: Limbo: A complete rewrite of SQLite in Rust
#38Earlier quoted context omitted.
Good luck for sure, but browsing their compatibility matrix, it looks like they are a LONG way off. By the looks of it, they have mostly read compatibility with little write capabilities (no alter table, for example).
That's fully in line with what they're announcing here. It's the announcement of a new project that has passed the prototyping stage, but one that has not reached the 1.0 stage.
correct, this is just the project being moved from fun personal side project from the company's CTO to an experimental stage as a company project.
There isn't a long term roadmap, or anything like that. I got pretty excited when I saw the results, though. It's less about the number of github stars - who the hell cares about those - but the contributors. Limbo already has a very nice list of contributors, which led me to believe there is something here!
Re: Limbo: A complete rewrite of SQLite in Rust
#39Clearly still in very early days:
uv run --with pylimbo --python 3.13 python
>>> import limbo
>>> con = limbo.connect("/tmp/content.db")
thread '' panicked at core/schema.rs:186:18:
not yet implemented: Expected CREATE TABLE statement
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
stack backtrace:
0: _rust_begin_unwind
1: core::panicking::panic_fmt
2: limbo_core::util::parse_schema_rows
3: _limbo::__pyfunction_connect
4: pyo3::impl_::trampoline::trampolineRe: Limbo: A complete rewrite of SQLite in Rust
#40Given 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!
A company that works with SQLite and prefers to write Rust has the expertise needed to rewrite SQLite in Rust. That’s what they’re doing.
All the other C code could be rewritten, this doesn’t stop or slow down any such effort. But for sure it was never going to be possible for a database provider to start making a memory safe implementation of libpng or something.