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

181–190 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#181

Post by [deleted] »

froh wrote: post #161
cryptonector wrote: post #158

Earlier quoted context omitted.

open source != Open Source. If I had meant the latter I would have written Open Source, but I wrote open source because I meant the former. How's that for being pedantic?

not helpful. capitalization is not bearing meaning in these contexts. open source means OSI compliant, broadly speaking, and licensed as such. in contrast, public domain doesn't exist in some jurisdictions, which is why sqlite as a company had to create an option to provide an official license. which they found so annoying that they charged a sweet fee to send a signed printed letter...

[deleted]

Re: Limbo: A complete rewrite of SQLite in Rust

#182

Post by cryptonector »

somat wrote: post #80
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…

Why does the fork have to gain traction? You keep and maintain your local fork that does what you need it to do. perhaps if you are charitable you share it with others. but you don't need to do this. and it just adds support burden.

If you don't care about traction then you wouldn't seek press for your fork to begin with. TFA is clearly seeking traction.

Re: Limbo: A complete rewrite of SQLite in Rust

#184

Post by odo1242 »

otterley wrote: post #179
odo1242 wrote: post #114

Earlier quoted context omitted.

Public domain rights differ across countries. So someone could put a work into the public domain and sue you in the one or two major countries where copyright can’t be disclaimed by the original author without a license, or where there isn’t legal precedent for it (this is purely theoretical and has never actually occurred before, it would also not be likely to succeed if it did happen). Also, it is technically possi…

Do you honestly believe any of the SQLite authors or its millions of users (especially deep-pocketed companies like Apple) lose any sleep at night over this?

No. It’s only really an issue in theory.

Re: Limbo: A complete rewrite of SQLite in Rust

#185

Post by callingbull »

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 Public Domain.

Is it though? The website does say "All of the code and documentation in SQLite has been dedicated to the public domain by the authors" but copyright law has no exception for "dedications" to the public domain. At best the authors are estopped from bringing suit but even that is unclear.

Re: Limbo: A complete rewrite of SQLite in Rust

#186

Post by smarx007 »

glommer wrote: post #55
Koshkin wrote: post #42

Limbo has been taken (as the name of a language), so this should be SQuaLor or something...

this is a codename, and if the project is to be successful, we don't expect to keep it.

Nothing is as permanent as something temporary.

Congrats on a great new undertaking!

Re: Limbo: A complete rewrite of SQLite in Rust

#187

Post by uecker »

gmokki wrote: post #86
AlotOfReading wrote: post #27

Earlier quoted context omitted.

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).

For very simple things C might be accidentally faster. But C lacks many modern data structures, which are critical for performance on modern hardware and bigger input data.

What do you mean by C lacks many modern data structures?

Re: Limbo: A complete rewrite of SQLite in Rust

#188

Post by throw_me_uwu »

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!

It'd be cool if it was possible to run user provided SQL queries safely without sandboxing/wasm.

Re: Limbo: A complete rewrite of SQLite in Rust

#189

Post by callingbull »

Aloisius wrote: post #139
wongarsu wrote: post #98

Earlier quoted context omitted.

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 ver…

SQLite didn't just say, "it's public domain." They explicitly state, "Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original SQLite code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means." One can buy a "license" if one's company is run by idle lawyers: https://www.sqlite.org/purchase/license

> They explicitly state, "Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original SQLite code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means."

It's not clear this is a license grant rather than legal advice (which would be correct legal advice if the code were public domain, but it is not).

Re: Limbo: A complete rewrite of SQLite in Rust

#190

Post by neverartful »

larkost wrote: post #159
IshKebab wrote: post #112

Earlier quoted context omitted.

They did add support for strict type checking fairly recently, and you can turn on foreign key checking I think.

Here is the STRICT table type page: https://www.sqlite.org/stricttables.html It is fairly straightforward: you just have to add STRICT to your table definition and you have it. 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 da…

I don't view opt-in as a very good defaults for these.
Post reply on HN