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

131–140 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#131

Post by zsims »

cryptonector wrote: post #21
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!

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 U.S. government wants everyone to abandon C/C++ -- how will they do this if they depend on SQLite3?

ABI, the same way you don't need the Linux kernel to be rewritten to remove your app dependency on C/C++

Re: Limbo: A complete rewrite of SQLite in Rust

#132

Post by ngrilly »

wgjordan wrote: post #69

> For maximum performance, users have to choose WAL mode over journal mode, disable POSIX advisory locks, etc. Speaking of "wal" mode, is "wal2" mode [1] on your radar for this project to prevent wal files from growing indefinitely in a busy system? [1] https://sqlite.org/cgi/src/doc/wal2/doc/wal2.md

Wondering about this as well :) That would be a game changer.

Re: Limbo: A complete rewrite of SQLite in Rust

#133

Post by neverartful »

lolinder wrote: post #129
neverartful wrote: post #108

Earlier quoted context omitted.

If I were to fork SQLite, drawing users away from the main project would be a non-goal. The goal would be to get strict tables and foreign key constraints enforced 100% of the time.

Yeah, I would assume that any project like this would strive to be a soft fork that just has a few minimal patches to address specific needs, not something that actually tries to compete with the original.

Agreed! If I were to fork sqlite, that would be my aim.

Re: Limbo: A complete rewrite of SQLite in Rust

#134

Post by CorrectHorseBat »

bruce511 wrote: post #115
quotemstr wrote: post #103

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…

Public Domain is not Free Software (in the FSF sense) because it has none of the encumbrances of a Free Software license. In other words you don't use PD software "like Free Software". You can use it in many places where Free Software would not be permissible. In terms of -developer- freedom, public domain is top of the pile, the Open Source, then Free Software. In terms of -user- freedoms Free Software is top of the…

Open source and Free software have different philosophies, but in practice they are essentially the same. You are thinking about copyleft vs non-copyleft. BSD, MIT, CC0 are all Free Software licenses but not copyleft.

Re: Limbo: A complete rewrite of SQLite in Rust

#135

Post by erik_seaberg »

quotemstr wrote: post #103
CorrectHorseBat wrote: post #87

Earlier quoted context omitted.

You should read the text, it's not about calling elephants bananas but real issues with software in the public domain

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.

Re: Limbo: A complete rewrite of SQLite in Rust

#136

Post by chasil »

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)

Re: Limbo: A complete rewrite of SQLite in Rust

#137

Post by fatbird »

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!

As a counterpoint, doing a rewrite of an example of the best C codebases gives you a much more interesting comparison between the languages. Rewriting a crappy C codebase in a modern, memory safe language is virtually guaranteed to result in something better. If a carefully executed rewrite of SQLite in Rust doesn't produce improvements (or some difficult tradeoffs), that's very informative about the relative virtues of C and Rust.

Re: Limbo: A complete rewrite of SQLite in Rust

#138

Post by pizlonator »

AlotOfReading wrote: post #7
xray2 wrote: post #5

I’ll take the faster c version anyday over the rust. How are those conditional if statements working for you all?

The benchmarks in the post indicate that Limbo is more performant than SQLite, not less.

That doesn't mean much until it's got feature parity.

Re: Limbo: A complete rewrite of SQLite in Rust

#139

Post by Aloisius »

wongarsu wrote: post #98
bruce511 wrote: post #59

Earlier quoted context omitted.

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

Post reply on HN