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

101–110 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#101

Post by 0x457 »

AlotOfReading wrote: post #27
jsheard wrote: post #15

Earlier quoted context omitted.

Related: https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn... C libraries aren't automatically the fastest option, there's a lot of C code which has stagnated on the performance front but is still widely used because it's battle tested and known to be robust by C standards.

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

> Fast Rust demands considerably more thoughtfulness from the programmer (at least for me).

While fast code requires thoughtfulness regardless of the language, I think rust lets you focus on the fast aspect more because rustc ensures _some_ safety and correctness.

I can write fast and very unsafe C code fast, but I write code that just as fast , but safer in rust faster than in C.

Re: Limbo: A complete rewrite of SQLite in Rust

#102

Post by dotancohen »

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.

An SQLite fork will have a hard time being compelling enough to draw users away from the main project. Being written in Rust is the most compelling reason that I could think of. SQLite has many annoying quirks (foreign key constraints disabled by default and non-strongly-typed columns are my two pain points) but a fork that addresses them would still not pull me away from the original project that I have so much trust in.

Re: Limbo: A complete rewrite of SQLite in Rust

#103

Post by quotemstr »

CorrectHorseBat wrote: post #87
quotemstr wrote: post #78

Earlier quoted context omitted.

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

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 the real world, you can safely do whatever you want with public domain software. It counts as free software. That half the planet nowadays uses SQLite and treats it as free software is testament to this reality. Obscure license pedanticism just doesn't inform the choices of anyone actually building.

Re: Limbo: A complete rewrite of SQLite in Rust

#104

Post by neverartful »

paulryanrogers wrote: post #96
avinassh wrote: post #19

Earlier quoted context omitted.

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?

What is meant by a 'hard fork'? Are there different kinds of forks?

Re: Limbo: A complete rewrite of SQLite in Rust

#105

Post by odo1242 »

thih9 wrote: post #71
wmf wrote: post #65

Earlier quoted context omitted.

Public domain is a form of open source.

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

Technically true, though this distinction only matters in a few countries.

Re: Limbo: A complete rewrite of SQLite in Rust

#106

Post by promano »

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…

The Business Source License is not an open source license. Open source does mean "free to use without encumbrance" - see points 5 and 6 of the Open Source Definition at https://opensource.org/osd

Re: Limbo: A complete rewrite of SQLite in Rust

#107

Post by odo1242 »

promano wrote: post #106
otterley wrote: post #89

Earlier quoted context omitted.

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…

The Business Source License is not an open source license. Open source does mean "free to use without encumbrance" - see points 5 and 6 of the Open Source Definition at https://opensource.org/osd

Yea - software released under the BSL is “source available”, not open source.

Re: Limbo: A complete rewrite of SQLite in Rust

#108

Post by neverartful »

dotancohen wrote: post #102
lolinder wrote: post #77

Earlier quoted context omitted.

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.

An SQLite fork will have a hard time being compelling enough to draw users away from the main project. Being written in Rust is the most compelling reason that I could think of. SQLite has many annoying quirks (foreign key constraints disabled by default and non-strongly-typed columns are my two pain points) but a fork that addresses them would still not pull me away from the original project that I have so much trus…

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.

Re: Limbo: A complete rewrite of SQLite in Rust

#110

Post by otterley »

promano wrote: post #106
otterley wrote: post #89

Earlier quoted context omitted.

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…

The Business Source License is not an open source license. Open source does mean "free to use without encumbrance" - see points 5 and 6 of the Open Source Definition at https://opensource.org/osd

Approximately zero people who make real business decisions care what the OSI considers a "real open-source license" to be. They care what the text of the license says.

Also, many licenses, such as the GPL (one of the very first "open source" licenses), have certain encumbrances; you cannot redistribute GPL-licensed software without either including its source code or making it readily available.

Post reply on HN