151–160 of 238 posts
I am assuming that DO-178B certification for the Rust variant is not on the table. https://www.sqlite.org/hirely.html https://www.sqlite.org/qmplan.html https://www.sqlite.org/th3.html The name "Limbo" is also used by a post-C/UNIX language from AT&T for the Inferno operating system. https://en.wikipedia.org/wiki/Limbo_(programming_language)
Earlier quoted context omitted.
> It is to highlight that we already reached a good level of performance this early in the project. This is the right thing to do. It's a pity so many projects don't keep an eye on performance from the very first day. Getting high performing product is a process, not a single task you apply at the end. Especially in a performance critical system like a database, if you don't pay attention to performance and instead y…
thanks. I am sad, but not that surprised, that a lot of people here are interpreting this as we claiming that we're already faster than sqlite all over. I don't even care about being faster than sqlite, just not being slower, this early, is already the win I'm looking for.
Earlier quoted context omitted.
I read the text: it's license hermenuetics at best and FUD at worst. Has there been a single instance in recorded history of the author of a public domain work trying to enforce usage, modification, or distribution permissions. Sure, you can point to theoretical variation in the precise semantics of the public domain in various jurisdictions, but it feels like a bar exam puzzle, not a real world practical concern. In…
It might seem really unlikely any acquirer would ever sue, but if your big company has compliance auditors they will need to see something in black and white.
They mention testing that bytecode generation generates the exact same results as SQLite... Does this exclude writing new optimization passes that are not in sqlite?
Earlier quoted context omitted.
What is meant by a 'hard fork'? Are there different kinds of forks?
To me, a "hard" fork is one where you plan not to maintain any compatibility with your upstream and not to share any future code in either way (neither from original to fork nor back). "Soft" forks often retain a degree of compatibility, and some future developments can be shared. (In this case, since it's a rewrite in Rust, it's not actually a fork at all, I think)
Earlier quoted context omitted.
That was my take when LibSQL was announced. And it still is and would be my take if LibSQL remains C-coded. But a Rust-coded rewrite of SQLite3 or LibSQL is a different story. The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary, and they don't accept contributions to any of either. This incentivizes anyone who needs support and/or new features in SQLite3 to join the…
>> The SQLite3 business model is that SQLite3 is open source This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. The distinction is subtle, but it is important.
How's that for being pedantic?
Earlier quoted context omitted.
Code quality is not the only thing to consider. Some people would love to see something like SQLite with 2 important changes: referential integrity that respects the DDL and strict tables that also respects the DDL.
They did add support for strict type checking fairly recently, and you can turn on foreign key checking I think.
And the FOREIGN KEY support is here: https://www.sqlite.org/foreignkeys.html The two requirements are that your build not have it disabled, and that you execute `PRAGMA foreign_keys = ON;` when you open the database (every time you open the database).
I could trivially write “an SQLite clone” that could execute `SELECT * FROM users LIMIT 1` even faster than either this or SQLite—if that's the only string I accepted as input!