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

Why Is SQLite Coded In C

sqlite.org

Post reply on HN
Print view View original

311–320 of 411 posts

Re: Why Is SQLite Coded In C

#311

Post by etruong42 »

saalweachter wrote: post #51

I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…

To build excitement in a project and potentially release new versions with new features, all more safely than adding C code.

Re: Why Is SQLite Coded In C

#312

Post by 1vuio0pswjnm7 »

Why doesn't ON CONFLICT(column_name) accept multiple arguments, i.e., multiple columns

One stupid workaround is combining multiple columns into one, with values separated by a space, for example. This works when each column value is always a string containing no spaces

Another stupid workaround, probably slower, might be to hash the multiple columns into a new column and use ON CONFLICT(newcolumn_name)

Re: Why Is SQLite Coded In C

#313

Post by a-dub »

csande17 wrote: post #304
a-dub wrote: post #71

Earlier quoted context omitted.

sqlite3 has one (apparently this is called "the amalgamation") c source file that is ~265 kloc (!) long with external dependencies on zlib, readline and ncurses. built binaries are libsqlite3.so at 4.8M and sqlite3 at 6.1M. turso has 341 rust source files spread across tens of directories and 514 (!) external dependencies that produce (in release mode) 16 libraries and 7 binaries with tursodb at 48M and libturso_sqli…

I don't think the SQLite authors actually edit the single giant source file directly. Their source control repository has the code split up into many separate files, which are combined into "the amalgamation" by a build script: https://github.com/sqlite/sqlite/tree/master/src

yeah i saw that afterwards. they do it to squeeze more optimization out of the compiler by putting everything in one compilation unit. given the prominence of the library i have to wonder if this was an input to zig's behind-the-scenes single compilation unit design choice...

Re: Why Is SQLite Coded In C

#314

Post by uecker »

dwattttt wrote: post #252
uecker wrote: post #206

Earlier quoted context omitted.

As long as it is possible to produce a OOB in something as simple as a matrix transpose, Rust also does not work: https://rustsec.org/advisories/RUSTSEC-2023-0080.html .

While a package with 10 million all-time downloads is nothing to sneeze at, it's had one memory corruption bug reported in its ~7 year life. It's being compared to a C library that's held to extremely high standards, yet this year had two integer overflow CVEs and two other memory corruption CVEs. SQLite is a lot more code, but it's also been around a lot longer.

The point is that matrix transpose should be trivial. But my main point really is that looking at CVEs is just nonsense. In both cases it is is a rather meaningless.

Re: Why Is SQLite Coded In C

#315

Post by krior »

guest_reader wrote: post #282
krior wrote: post #186

Earlier quoted context omitted.

C is so simple, that you will need to read a 700-page, comitee-written manual befor you can attempt to write it correctly.

> C is so simple, that you will need to read a 700-page, comitee-written manual befor you can attempt to write it correctly. The official C99 standard document is typically about 210 pages.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

Admittedly the 700 pages include the appendix and it is only a draft version, but still...

Re: Why Is SQLite Coded In C

#316

Post by RhysU »

eusto wrote: post #231
saalweachter wrote: post #51

I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…

I think that if SQLite would suddenly have to add a bunch of new features, the discussion about rewriting it would be very relevant. I think we like to fool ourselves that decisions like these are based on performance considerations or maintainability or whatever, but in reality they would be based on time to market and skill availability in the areas where the team is being built. At the end of the day, SQLite is no…

These guys are, after all, running a business. If they thought the best thing for their business was a rewrite, they'd do it.

Re: Why Is SQLite Coded In C

#317

Post by metaltyphoon »

colejohnson66 wrote: post #284
hoppp wrote: post #157

Earlier quoted context omitted.

Then the rights will be sold to a FAANG or an open souce fork like libSQL will live on.

SQLite is public domain (as much as is legally possible). So there's no "rights" to "sell" except the trademark.

The testing suite is not open, which is one of the most important part of the project.

Re: Why Is SQLite Coded In C

#318

Post by 1vuio0pswjnm7 »

jasonthorsness wrote: post #21

“None of the safe programming languages existed for the first 10 years of SQLite's existence. SQLite could be recoded in Go or Rust, but doing so would probably introduce far more bugs than would be fixed, and it may also result in slower code.” Modern languages might do more than C to prevent programmers from writing buggy code, but if you already have bug-free code due to massive time, attention, and testing, and t…

This begs the question of why Rust evangelists keep targeting existing projects instead of focusing writing new, better software. In theory these languages should allow software developers to write programs that they would not, or could not, attempt using languages without automatic memory management

Instead what I see _mostly_ is re-writes and proposed re-writes of existing software, often software that has no networking functions, and/or relatively small, easily audited software that IMHO poses little risk of memory-related bugs

This is concerning to me as an end-user who builds their software from source because the effects on compilation, e.g., increased resource requirements, increased interdependencies, increased program size, decreased compilation speed, are significant

Re: Why Is SQLite Coded In C

#319

Post by steveklabnik »

uecker wrote: post #211
steveklabnik wrote: post #78

Earlier quoted context omitted.

You may be running into forwards compatibility issues, not backwards compatibility issues, which is what nightly is about. The Rust Project releases a new stable compiler every six weeks. Because it is backwards compatible, most people update fairly quickly, as it is virtually always painless. So this may mean, if you don’t update your compiler, you may try out a new package version and it may use features or standar…

But the original point "C99 vs something later" is also about forward compatibility issues.

Sure, I had originally responded to the "needs nightly Rust part" only.

Re: Why Is SQLite Coded In C

#320

Post by steveklabnik »

hoppp wrote: post #164
steveklabnik wrote: post #160

Earlier quoted context omitted.

You control the dependencies you put in Cargo.toml.

What about the dependencies of your dependencies? I don't put too many things in Cargo.toml and it still pulls like a hundred things

If you care about not having any dependencies, then choosing dependencies that themselves don't have many dependencies should be going into the ones that you choose.
Post reply on HN