Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Limbo: A complete rewrite of SQLite in Rust

turso.tech

Post reply on HN
Print view View original

91–100 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#91

Post by Intermernet »

quotemstr wrote: post #78
thih9 wrote: post #71

Earlier quoted context omitted.

No. At least according to the Open Source Initiative, public domain is not open source: https://opensource.org/blog/public-domain-is-not-open-source

Any definition of open source that doesn't include the public domain is out of touch with how real people use the words "open source" and is therefore useless. You can make up any definition you want, but if you insist on calling elephants "bananas", I'm not going to take you seriously

How people use the term "fair use" is out of touch with the legal definition. That doesn't change the legal definition, it means people use the term incorrectly.

Re: Limbo: A complete rewrite of SQLite in Rust

#92

Post by dotancohen »

encoderer wrote: post #68
nine_k wrote: post #52

Earlier quoted context omitted.

...as long as you can persuade the keepers of the proprietary test suite to agree to run it against your code.

Even without that, it’s helpful. It means there is less (no?) undefined behavior that you will need to emulate to maintain compatibility. You can just follow the spec.

If you can not run the test suite, then how do you know that you properly followed the spec? And did so securely? And in a performant manner? Even for edge cases? On obscure hardware, filesystems, and OSes? Even if the power cuts out? Or the cable to the hard drive (transactions)? Even if a stray cosmic ray flips a bit?

By the way, SQLite itself does not meet one of these criteria. Know which one? ))

Re: Limbo: A complete rewrite of SQLite in Rust

#93

Post by thih9 »

quotemstr wrote: post #78
thih9 wrote: post #71

Earlier quoted context omitted.

No. At least according to the Open Source Initiative, public domain is not open source: https://opensource.org/blog/public-domain-is-not-open-source

Any definition of open source that doesn't include the public domain is out of touch with how real people use the words "open source" and is therefore useless. You can make up any definition you want, but if you insist on calling elephants "bananas", I'm not going to take you seriously

The linked article mentions public domain.

Please note that public domain laws vary depending on the country. What you call a banana might mean something different elsewhere.

Re: Limbo: A complete rewrite of SQLite in Rust

#94

Post by dotancohen »

the_mitsuhiko wrote: post #79
danieljanes wrote: post #12

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. That was my take for many years but I have come around 180 degree on this. I think at this point it's very likely and most likely mandatory to eventually rewrite SQLite. In parts because of what is called out in the blog post: the tests are not public. More importantly, the entire project is not really open. And…

This reminds me of VIM - and after quite some time I believe that all VIM users will agree that adding NeoVIM to the ecosystem improved VIM itself. VIM 8 addressed over half the issues that led to the NeoVIM fork in the first place - with the exception of the issue of user contributions, of course.

Re: Limbo: A complete rewrite of SQLite in Rust

#96

Post by paulryanrogers »

avinassh wrote: post #19
eimrine wrote: post #16

Earlier quoted context omitted.

> It uses Asynchronous I/O Can it have more than 1 writer?

As of now it has a single writer, same like SQLite. But we plan to add MVCC with multiple writers in the future. Pekka has experimented with MVCC earlier: https://github.com/penberg/tihku

So a hard fork?

Re: Limbo: A complete rewrite of SQLite in Rust

#97

Post by encoderer »

dotancohen wrote: post #92
encoderer wrote: post #68

Earlier quoted context omitted.

Even without that, it’s helpful. It means there is less (no?) undefined behavior that you will need to emulate to maintain compatibility. You can just follow the spec.

If you can not run the test suite, then how do you know that you properly followed the spec? And did so securely? And in a performant manner? Even for edge cases? On obscure hardware, filesystems, and OSes? Even if the power cuts out? Or the cable to the hard drive (transactions)? Even if a stray cosmic ray flips a bit? By the way, SQLite itself does not meet one of these criteria. Know which one? ))

I’m not sure what your point is? Yes, it would be better if they would run their tests against your fork. But they won’t. Still, it’s better for the fork writer that they exist.

Re: Limbo: A complete rewrite of SQLite in Rust

#98

Post by wongarsu »

bruce511 wrote: post #59
cryptonector wrote: post #21

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.

It's a difference only insofar that in many jurisdictions their claim that it's public domain has no legal value. If it was truly public domain (e.g. if the authors were long dead) it would be open source. But far from all places allow you to arbitrarily put things in the public domain.

I'm a bit puzzled why SQLite doesn't solve this trivial issue by claiming the code is CC0-licensed. CC0 is made just for that: a very wordy way to make it as close to public domain as possible in each jurisdiction.

On the other hand, hobbyists won't care. As long as you trust them in their intention to have it open source they won't sue you for infringement either. And if as a company you need more assurance than "it's public domain" they are so nice to sell you a fancy legally-satisfying piece of paper for an undisclosed price. It's a subtle but clever way to get income from users with too much money

Re: Limbo: A complete rewrite of SQLite in Rust

#99

Post by robertlagrant »

otterley wrote: post #89
thih9 wrote: post #71

Earlier quoted context omitted.

No. At least according to the Open Source Initiative, public domain is not open source: https://opensource.org/blog/public-domain-is-not-open-source

It is absolutely true that a work can be in the public domain and not have source available (or even contributable). But that doesn't really matter to most people. The question for most people is not whether something is open source, but whether they can copy and make use of a work without being held liable for copyright infringement. SQLite happens to be both public domain and open-source to an extent (i.e., source…

No one's saying public domain isn't useful. You're replying to a comment that's specifically and solely combatting the idea that public domain means open source.

Re: Limbo: A complete rewrite of SQLite in Rust

#100

Post by neverartful »

lolinder wrote: post #77
neverartful wrote: post #43

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.

I might be missing something—is there a reason why rewriting it in Rust would be a prerequisite to adding these features, vs just starting a fork? And in this case the project intends to be fully compatible, so they wouldn't be able to unilaterally adopt or drop features anyway.

Agreed! Rewriting in Rust (or any other language) is not required for those features. A fork and modifying the existing C code could also result in those features (and I might do just that if it doesn't come around soon).
Post reply on HN