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

251–260 of 411 posts

Re: Why Is SQLite Coded In C

#251

Post by pjmlp »

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…

The author cleverly leaves out all the safer alternatives that have existed outside UNIX, and what was happening with computers outside Bell Labs during the 1970's.

Not only was Apple was able to launch the Mac Classic with zero lines of C code, their Pascal dialect lives on in Delphi and Free Pascal.

As one example.

Re: Why Is SQLite Coded In C

#252

Post by dwattttt »

uecker wrote: post #206
krior wrote: post #192

Earlier quoted context omitted.

That list alone sounds like it does not work.

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.

Re: Why Is SQLite Coded In C

#253

Post by biohazard2 »

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…

> there's also just no reason to rewrite SQLite in another language. […] But why would we want to throw away the perfectly good C implementation, and why would we expect the C experts who have been carefully maintaining SQLite for a quarter century to be the ones to learn a new language and start over?

The SQLite developers are actually open to the idea of rewriting SQLite in Rust, so they must see an advantage to it:

> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include: […] If you are a "rustacean" and feel that Rust already meets the preconditions listed above, and that SQLite should be recoded in Rust, then you are welcomed and encouraged to contact the SQLite developers privately and argue your case.

Re: Why Is SQLite Coded In C

#254

Post by bombcar »

ChrisRR wrote: post #245
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 is the argument against re-writing the linux base utils in rust. When they've had such widespread use for decades, a hell of a lot of bugs have been ironed out

Especially since memory bugs are only a subset of all bugs, and (perhaps) not even the most important subset.

Memory bugs are often implicated in security issues, but other bugs are more likely to cause data loss, corruption, etc.

Re: Why Is SQLite Coded In C

#255

Post by blibble »

slashdev wrote: post #109
3eb7988a1663 wrote: post #81

Earlier quoted context omitted.

It should be noted that project has no affiliation with the SQLite project. They just use the name for promotional/aspirational purposes. Which feels incredibly icky. Also, this is a VC backed project. Everyone has to eat, but I suspect that Turso will not go out of its way to offer a Public Domain offering or 50 year support in the way that SQLite has.

> They just use the name for promotional/aspirational purposes. Which feels incredibly icky. The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use. > Also, this is a VC backed project. Everyone has to eat, but I suspect that Turso will not go out of its way to offer a Public Domain offering or 50 year support in the way that SQLite has. It's MIT license open-source. And u…

> The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use.

try marketing your burger company as "The Next Evolution of McDonalds" and see what happens

Re: Why Is SQLite Coded In C

#256

Post by throw0101d »

Aurornis wrote: post #62
bfkwlfkjf wrote: post #16

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

I guess I don’t find that argument very compelling. If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested. This feels like chasing arbitrary 100% test coverage at the expense of safety. The code quality isn’t actually improved by omitting the checks even though it makes testing coverage go up.

> If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested.

“What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so.” — Mark Twain, https://www.goodreads.com/quotes/738123

Re: Why Is SQLite Coded In C

#257

Post by sgbeal »

dathinab wrote: post #97
bfkwlfkjf wrote: post #16

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

the problem is it's kinda an anti argument you basically say if deeply unexpected things happen you prefer you program doing widely arbitrary and as such potentially dangerous things over it having a clean abort or proper error. ... that doesn't seem right worse it's due to a lack of the used tooling and not a fundamental problem, not only can you test this branches (using fault injection) you also often (not always)…

> you prefer you program doing widely arbitrary and as such potentially dangerous things over it having a clean abort or proper error.

SQLite isn't a program, it's a library used by many other programs. As such, aborting is not an option. It doesn't do "wildly arbitrary" things - it reports errors to the client application and takes it on faith that they will respond appropriately.

Re: Why Is SQLite Coded In C

#258

Post by sgbeal »

steeleduncan wrote: post #235

> SQLite could be recoded in Go Sqlite has been recoded (automatically) in Go a while ago [1], and it is widely deployed > would probably introduce far more bugs than would be fixed It runs against the same test suite with no issues > and it may also result in slower code It is quite a lot slower, but it is still widely used as it turns out that the convenience of a native port outweighs the performance penalty in mo…

> It runs against the same test suite with no issues

It runs against the same public test suite. The proprietary test suite is much more intensive.

Re: Why Is SQLite Coded In C

#259

Post by belter »

Some of the most interesting comments are out of: "3. Why Isn't SQLite Coded In A "Safe" Language?"

"....Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy..."

"...Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages..."

Re: Why Is SQLite Coded In C

#260

Post by Hendrikto »

devjab wrote: post #241
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…

I quite like that Zig works a drop in for C in a few use cases. It's been very nice to utilize it along with our Python and regular C binaries. We attempted to move into Go because we really like the philosophy and opinions it force upon it's developers, but similar to interpreted languages it can be rather hard to optimize it. I'm sure people more talented than us would have an easy time with it, but they don't work…

> We attempted to move into Go […], but similar to interpreted languages it can be rather hard to optimize it. […] So it was easier to just go with Python

I don’t get that. You had trouble optimizing Go, so you went with Python?

Post reply on HN