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

241–250 of 411 posts

Re: Why Is SQLite Coded In C

#241

Post by devjab »

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 for us. So it was easier to just go with Python and a few parts of it handled by C (and in even fewer cases Zig).

I guess we could use Rust and I might be wrong on this, but it seemed like it would be a lot of work to utilize it compared to just continuing with C and gradually incorprating Zig, and we certainly don't write bug free C.

Re: Why Is SQLite Coded In C

#242

Post by Sammi »

weinzierl wrote: post #216
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…

"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." We will see. On the Rust side there is Turso which is pretty active. https://turso.tech/

The Sqlite team in stuck in the classic dilemma. They are stuck with their existing thing because it is so big, that you can't just stop the world for you existing users and redo it. Meanwhile some small innovator comes along and builds the next thing because why not, they don't have anything holding them back. This is classic Innovator's Dilemma and Creative Destruction. This has of course not happened yet and we have to wait and see if Turso can actually deliver, but the Turso team is extremely talented and their git repo history is on fire, so it is definitely a possible scenario.

Re: Why Is SQLite Coded In C

#243

Post by casparvitch »

Jtsummers wrote: post #166
casparvitch wrote: post #41

Earlier quoted context omitted.

Why can't `if condition { panic(err) }' be used in go as an assert equivalent?

Because C's assert gets compiled out if you have NDEBUG defined in your program. How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)?

Ah apologies I misunderstood, thanks

Re: Why Is SQLite Coded In C

#245

Post by ChrisRR »

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

Re: Why Is SQLite Coded In C

#246

Post by jeroenhd »

hoppp wrote: post #158
steveklabnik wrote: post #27

Earlier quoted context omitted.

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

Rust has dependency hell and supply chain attacks like with npm.

C has the same problem, but it lacks a common package manager like other languages do. Just because you need to clone git submodules or run package manager commands (hope you're on a supported OS version!) doesn't mean C doesn't have package manager issues.

C projects avoiding dependencies entirely just end up reimplementing work. You can do that in any language.

Re: Why Is SQLite Coded In C

#247

Post by ChrisRR »

coolThingsFirst wrote: post #65
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.

This is a dumb argument, it's like saying for a perfect human being there's no need for smart pointers, garbage collection or the borrow checker.

I can't figure out how you've come to that equivalence

Re: Why Is SQLite Coded In C

#248

Post by ChrisRR »

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

That doesn't guarantee no bugs. It just means that the existing behaviour covered by the tests is still the same. It may introduce new issues in untested edge cases or performance issues

Re: Why Is SQLite Coded In C

#249

Post by echoangle »

Jtsummers wrote: post #166
casparvitch wrote: post #41

Earlier quoted context omitted.

Why can't `if condition { panic(err) }' be used in go as an assert equivalent?

Because C's assert gets compiled out if you have NDEBUG defined in your program. How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)?

> How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)?

https://stackoverflow.com/questions/36703867/golang-preproce...

Wouldn't this work? Surely the empty function would be removed completely during compilation?

Re: Why Is SQLite Coded In C

#250

Post by 6r17 »

If I remember correctly most of SQLite "closed-source" leverage comes from the test-suite - which probably cannot transpose to another language as easily. Ultimately there are already other solutions coming up re-writing it in rust or go.
Post reply on HN