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

231–240 of 411 posts

Re: Why Is SQLite Coded In C

#231

Post by eusto »

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 not being rewritten because the cost of doing so is not justifiable

Re: Why Is SQLite Coded In C

#233

Post by ncruces »

nabhasablue wrote: post #193
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…

there is already an sqlite port in Go :) https://gitlab.com/cznic/sqlite

That's not a port. That's an extremely impressive machine translation of C to Go.

The output is a non-portable half-a-million LoC Go file for each platform.

Re: Why Is SQLite Coded In C

#234

Post by ginko »

plainOldText wrote: post #4

I’d be curious to know what the creators of SQLite would have to say about Zig. Zig gives the programmer more control than Rust. I think this is one of the reasons why TigerBeetle is written in Zig.

I'm generally a fan of Zig but it's in no way stable enough to write something like sqlite in it.

Re: Why Is SQLite Coded In C

#235

Post by steeleduncan »

> 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 most cases.

I don't think SQLite should be rewritten in Go, Rust, Zig, Nim, Swift ... but ANSI C is a subset of the feature set of most modern programming languages. Projects such as this could be written and maintained in C indefinitely, and be automatically translated to other languages for the convenience of users in those languages

[1] https://pkg.go.dev/modernc.org/sqlite

Re: Why Is SQLite Coded In C

#236

Post by sim7c00 »

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…

> would probably introduce far more bugs than would be fixed

It runs against the same test suite with no issues

- that proves nothing about bugs existing or not.

Re: Why Is SQLite Coded In C

#237

Post by zimpenfish »

AdamJacobMuller wrote: post #128
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…

One good reason is that people have written golang adapters, so that you can use sqlite databases without cgo. I agree to what I think you're saying which is that "sqlite" has, to some degree, become so ubiquitous that it's evolved beyond a single implementation. We, of course, have sqlite the C library but there is also sqlite the database file format and there is no reason we can't have an sqlite implementation in…

> One good reason is that people have written golang adapters, so that you can use sqlite databases without cgo.

There's also the Go-wrapped WASM build of the C sqlite[0] which is handy.

[0] https://github.com/ncruces/go-sqlite3

Re: Why Is SQLite Coded In C

#239

Post by ahoka »

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…

Sure they did exist, almost no one cared though.

Re: Why Is SQLite Coded In C

#240

Post by aw1621107 »

csande17 wrote: post #224
aw1621107 wrote: post #217

Earlier quoted context omitted.

> I linked the same bug you did in the comment that that's a reply to Ah, my apologies. Not sure exactly how I managed to miss that. That being said, I guess I might have read that bit of your comment different than you had in mind; I was thinking of whether the Rust devs were dismissing language design issues as compiler bugs, not what third parties (albeit one with an unusually relevant history in this case) may th…

Oh, I didn't realize steveklabnik wasn't an official member of the project anymore (as of 2022 apparently: https://blog.rust-lang.org/2022/01/31/changes-in-the-core-te... ). I do think he still expressed this position back when he was a major public face of the language, but it seems unfair to single him out and dig through his comment history. Rust's marketing is pretty grassroots in general, but even current offici…

Yeah, Steve has been "just" a well-informed third party for a while now. I would be curious if he has commented on that specific issue before; usually when unsoundness comes up it's cve-rs which is mentioned.

> but even current official sources like https://rust-lang.org/ say things like "Rust’s rich type system and ownership model guarantee memory-safety" that are only true of the vague-ideal "Rust language" and are not true of the type system they actually designed and implemented in the Rust compiler.

That's an understandable point, though I think something similar would arguably still apply even if Rust had a "proper" spec since a "proper" spec doesn't necessarily rule out underspecification/omissions/mistakes/etc, both in the spec and in the implementation. A "real" formal spec à la WebAssembly might solve that issue, but given the lack of time/resources for a "normal" spec at the time a "real" one would have been a pipe dream at best.

That being said, I think it's an interesting question as to what should be done if/when you discover an issue like the trait coherence one, whether you have a spec or not. "Aspirational" marketing doesn't exactly feel nice, but changing your marketing every time you discover/fix a bug also doesn't exactly feel nice for other reasons.

Bit of a fun fact - it appears that the particular trait coherence issue actually has existed in some form since Rust 1.0, and was only noticed a few years later when the issue was filed. Perhaps a proper specification effort would have caught it (especially since one of the devs said they had concerns when implementing a relevant check), but given it had taken that long to discover I wouldn't be too surprised if it would have been missed anyway.

Post reply on HN