Interesting that you didn't respond to the substance of my comment - the technical reasons that cloud SQLite works so well. That after making an awfully wrong categorical statement "even though it's completely at odds with SQLite's intended use-case".
> [Rust C API] ... I'm generally unfamiliar with Rust
Evidently. But then should you be writing snarky comments like "We're going to rewrite it in Rust because that's going to make it inherently better (and don't question this)". Really makes it sound like you know that the choice of Rust should be questioned.
For what it's worth, Rust codebases can be compiled to expose a C ABI that other applications can integrate with. For example, the rustls project exposes an OpenSSL compatible interface (https://www.memorysafety.org/blog/rustls-nginx-compatibility...) which makes it trivial to integrate into applications that expect OpenSSL.
> [Limbo SQLite compatibility] ... But if this is not the case, or this is not what “Limbo” is aiming for here
You know ... you could just read a little before writing so much. On https://github.com/tursodatabase/limbo it says their stated goals are - "SQLite compatibility. SQL dialect support. File format support. SQLite C API". They want to expose the exact same C API that SQLite exposes.
Does that sufficiently address your concerns around Rust codebases being used from other languages and Limbo's compatibility with SQLite?
---
> even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
To be clear, at no point did anyone say it was "an objectively better replacement for SQLite". No one said it, because Limbo is years away from feature parity.
It seems acceptable to aim to build something better than SQLite. Having a goal is fine, because it points them in a direction. But for some reason, you're getting upset that ... they have goals? Bizarre.
And if their reach feature parity while using io_uring, then yeah it is likely that it will outperform SQLite which uses synchronous I/O.
---
> Testing
We are agreed, it remains to be seen if DST can make something as reliable SQLite's testing strategy has made SQLite. But we'll only see it if someone tries, and that is something you seem quite hostile to.
At least Limbo will do their testing in the open and we can all learn from it whether they succeed or not.
---
> Code of Conduct
I feel changing/replacing files from the repo is important, because it feels similar to replacing a LICENSE file. You can't relicense someone's work just because you feel like it. Similarly, if the Code of Ethics had been replaced in the repo, that would have felt similar to relicensing, although not the same.
Again, I'll be blunt. Do you want anyone who works on this public domain code to adopt principles like "Prefer nothing more than the love of Christ". Not being Christian, I personally prefer nearly all things to the love of Christ. I know I'm not the only developer who feels this way.
The force with which you're arguing this makes me wonder if you really want this sort of religious fervour to become more widespread in open source. Where some projects are Christian, some are Muslim and so on. Of course, then we can really segment the projects into Catholic, Protestant, Anglican, Eastern Orthodox, Sunni, Shia - really experience the full power of religion in open source software development. Wouldn't it be great when OSS projects have a code of ethics that start with "All current developers agree that there is no deity but Allah and Mohammad is his Prophet".
From a legal point of view - there is no reason to adopt this because the code is in public domain. From an ethical point of view - there is no reason for the libSQL to adopt a code that they likely personally disagree with ("all current developers agree ..."). From a practical point of view - they want to encourage contributors, not discourage them (like Hipp was and is), so there's no reason to adopt a code that deliberately drives away contributors.
I don't know how you feel because you carefully dance around that. You simply criticise the libSQL folks for anything they do. Criticising is easy, doing is difficult. So say precisely what Code libSQL and Limbo should adopt and why you think it's such a good idea.
> [Rust C API] ... I'm generally unfamiliar with Rust
Evidently. But then should you be writing snarky comments like "We're going to rewrite it in Rust because that's going to make it inherently better (and don't question this)". Really makes it sound like you know that the choice of Rust should be questioned.
For what it's worth, Rust codebases can be compiled to expose a C ABI that other applications can integrate with. For example, the rustls project exposes an OpenSSL compatible interface (https://www.memorysafety.org/blog/rustls-nginx-compatibility...) which makes it trivial to integrate into applications that expect OpenSSL.
> [Limbo SQLite compatibility] ... But if this is not the case, or this is not what “Limbo” is aiming for here
You know ... you could just read a little before writing so much. On https://github.com/tursodatabase/limbo it says their stated goals are - "SQLite compatibility. SQL dialect support. File format support. SQLite C API". They want to expose the exact same C API that SQLite exposes.
Does that sufficiently address your concerns around Rust codebases being used from other languages and Limbo's compatibility with SQLite?
---
> even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
To be clear, at no point did anyone say it was "an objectively better replacement for SQLite". No one said it, because Limbo is years away from feature parity.
It seems acceptable to aim to build something better than SQLite. Having a goal is fine, because it points them in a direction. But for some reason, you're getting upset that ... they have goals? Bizarre.
And if their reach feature parity while using io_uring, then yeah it is likely that it will outperform SQLite which uses synchronous I/O.
---
> Testing
We are agreed, it remains to be seen if DST can make something as reliable SQLite's testing strategy has made SQLite. But we'll only see it if someone tries, and that is something you seem quite hostile to.
At least Limbo will do their testing in the open and we can all learn from it whether they succeed or not.
---
> Code of Conduct
I feel changing/replacing files from the repo is important, because it feels similar to replacing a LICENSE file. You can't relicense someone's work just because you feel like it. Similarly, if the Code of Ethics had been replaced in the repo, that would have felt similar to relicensing, although not the same.
Again, I'll be blunt. Do you want anyone who works on this public domain code to adopt principles like "Prefer nothing more than the love of Christ". Not being Christian, I personally prefer nearly all things to the love of Christ. I know I'm not the only developer who feels this way.
The force with which you're arguing this makes me wonder if you really want this sort of religious fervour to become more widespread in open source. Where some projects are Christian, some are Muslim and so on. Of course, then we can really segment the projects into Catholic, Protestant, Anglican, Eastern Orthodox, Sunni, Shia - really experience the full power of religion in open source software development. Wouldn't it be great when OSS projects have a code of ethics that start with "All current developers agree that there is no deity but Allah and Mohammad is his Prophet".
From a legal point of view - there is no reason to adopt this because the code is in public domain. From an ethical point of view - there is no reason for the libSQL to adopt a code that they likely personally disagree with ("all current developers agree ..."). From a practical point of view - they want to encourage contributors, not discourage them (like Hipp was and is), so there's no reason to adopt a code that deliberately drives away contributors.
I don't know how you feel because you carefully dance around that. You simply criticise the libSQL folks for anything they do. Criticising is easy, doing is difficult. So say precisely what Code libSQL and Limbo should adopt and why you think it's such a good idea.