> [DST and Antithesis is just as good if not better than TH3]
Remains to be proven.
> So they "replaced" nothing. They simply added their own code of conduct
This is pedantic. Yes, the Code of Ethics is on the SQLite website, and not in its source directory, so yes, technically cloning the repo and adding a Code of Conduct is not “replacing” the Code of Ethics in terms of files in repositories. Arguing this point as you have is simply inane. SQLite has a Code of Ethics, and libSQL/“Limbo” are unbeholden to the SQLite Code of Ethics and instead have a Code of Conduct. Taking umbrage with describing this as “replacing the Code of Ethics with a Code of Conduct” is just being pedantic for the sake of it.
> Only someone with a warped mind could find something objectionable about starting small and iterating with the community.
Wholly unnecessary, overemotional ad hominem. If SQLite was abandonware then there would be no issue—but it's not, it's great software that is regularly updated (without a “community”, in the sense being discussed here), so, announcing a rewrite long before it's done and declaring how much better than SQLite it is going to be comes across as rather untoward.
For many people, such as myself, the lack of “community” in the SQLite project is a selling point, rather than some kind of problem—such that when an incomplete fork/rewrite with an emphasis on “community” is announced, myself and many others see that as yet another point against it. Sure, you're going to have many naive or otherwise inexperienced developers who care more about Codes of Conduct and “community policing” and “feeling like you're part of a community” or whatever, and that's fine, go right ahead and have fun with that. But for the rest of us, who enjoy using well-made software without getting into any of that nonsense, SQLite and the way it goes about doing things will remain the superior option.
> What should they be writing it in? I notice you don't say. You reckon they should start a new C code base in 2024?
Part of what makes SQLite so useful is that it is written in C, and therefore is easy to compile and integrate into just about anything. I'm generally unfamiliar with Rust, so I don't know, maybe it's possible to make a SQLite clone in Rust with full C ABI compatibility. But if this is not the case, or this is not what “Limbo” is aiming for here, then yes, it is strictly worse in the general sense than SQLite, except for specific use-cases.
If libSQL and “Limbo” were being presented as alternatives to SQLite that are more useful for specific use-cases, then I wouldn't've felt the need to comment in the first place. The problem is when you begin undertaking a project of this enormity, baselessly assert that the thing you're trying to do is straight-up better than the existing SQLite gold standard, and even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
Additionally, naming your SQLite rewrite library “libSQL” is also quite clearly a means of semantically positioning it as a better, “more ‘modern’”, more generic SQL library than SQLite—and that's great marketing for a specific kind of developer. When searching e.g. Twitter for “libSQL”, one will find posts where people describe things they're working on, saying things like, “Uses SQLite for database (plan to replace with libSQL soon!)”, which proves my point—they've succeeded in positioning libSQL as “a more modern SQLite”, to the point where some developers see the need to replace SQLite with libSQL just for the sake of doing so. Again, this would be totally fine if SQLite was abandonware—but, once again, it's quite the opposite of that.
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.
Remains to be proven.
> So they "replaced" nothing. They simply added their own code of conduct
This is pedantic. Yes, the Code of Ethics is on the SQLite website, and not in its source directory, so yes, technically cloning the repo and adding a Code of Conduct is not “replacing” the Code of Ethics in terms of files in repositories. Arguing this point as you have is simply inane. SQLite has a Code of Ethics, and libSQL/“Limbo” are unbeholden to the SQLite Code of Ethics and instead have a Code of Conduct. Taking umbrage with describing this as “replacing the Code of Ethics with a Code of Conduct” is just being pedantic for the sake of it.
> Only someone with a warped mind could find something objectionable about starting small and iterating with the community.
Wholly unnecessary, overemotional ad hominem. If SQLite was abandonware then there would be no issue—but it's not, it's great software that is regularly updated (without a “community”, in the sense being discussed here), so, announcing a rewrite long before it's done and declaring how much better than SQLite it is going to be comes across as rather untoward.
For many people, such as myself, the lack of “community” in the SQLite project is a selling point, rather than some kind of problem—such that when an incomplete fork/rewrite with an emphasis on “community” is announced, myself and many others see that as yet another point against it. Sure, you're going to have many naive or otherwise inexperienced developers who care more about Codes of Conduct and “community policing” and “feeling like you're part of a community” or whatever, and that's fine, go right ahead and have fun with that. But for the rest of us, who enjoy using well-made software without getting into any of that nonsense, SQLite and the way it goes about doing things will remain the superior option.
> What should they be writing it in? I notice you don't say. You reckon they should start a new C code base in 2024?
Part of what makes SQLite so useful is that it is written in C, and therefore is easy to compile and integrate into just about anything. I'm generally unfamiliar with Rust, so I don't know, maybe it's possible to make a SQLite clone in Rust with full C ABI compatibility. But if this is not the case, or this is not what “Limbo” is aiming for here, then yes, it is strictly worse in the general sense than SQLite, except for specific use-cases.
If libSQL and “Limbo” were being presented as alternatives to SQLite that are more useful for specific use-cases, then I wouldn't've felt the need to comment in the first place. The problem is when you begin undertaking a project of this enormity, baselessly assert that the thing you're trying to do is straight-up better than the existing SQLite gold standard, and even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
Additionally, naming your SQLite rewrite library “libSQL” is also quite clearly a means of semantically positioning it as a better, “more ‘modern’”, more generic SQL library than SQLite—and that's great marketing for a specific kind of developer. When searching e.g. Twitter for “libSQL”, one will find posts where people describe things they're working on, saying things like, “Uses SQLite for database (plan to replace with libSQL soon!)”, which proves my point—they've succeeded in positioning libSQL as “a more modern SQLite”, to the point where some developers see the need to replace SQLite with libSQL just for the sake of doing so. Again, this would be totally fine if SQLite was abandonware—but, once again, it's quite the opposite of that.