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

211–220 of 411 posts

Re: Why Is SQLite Coded In C

#211

Post by uecker »

steveklabnik wrote: post #78
dgfitz wrote: post #63

Earlier quoted context omitted.

Good to know, maybe I’ll give it a whirl. I’d been under the (mistaken, apparently) impression that if one didn’t update monthly they were going to have a bad time.

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.

Re: Why Is SQLite Coded In C

#212

Post by stoltzmann »

slashdev wrote: post #108
assimpleaspossi wrote: post #47

Earlier quoted context omitted.

>>SQLite is being rewritten in Rust SQLite is NOT being rewritten in Rust! >>Turso Database is an in-process SQL database written in Rust, compatible with SQLite.

It's a ground up rewrite. It's not an official rewrite, if that's what you mean. Words are hard.

So a reimplementation, not a rewrite.

Re: Why Is SQLite Coded In C

#213

Post by uecker »

bsder wrote: post #204
01HNNWZ0MV43FF wrote: post #15

Earlier quoted context omitted.

It is. You can also write it in C++ or Rust and expose a C API+ABI, and then you're distributing a binary library that the OS sees as very similar to a C library. Occasionally when working in Lua I'd write something low-level in C++, wrap it in C, and then call the C wrapper from Lua. It's extra boilerplate but damn is it nice to have a REPL for your C++ code. Edit: Because someone else will say it - Rust binary arti…

> It is. You can also write it in C++ or Rust and expose a C API+ABI, and then you're distributing a binary library that the OS sees as very similar to a C library. If I want a "C Library", I want a "C Library" and not some weird abomination that has been surgically grafted to libstdc++ or similar (but be careful of which version as they're not compatible and the name mangling changes and ...). This isn't theoretical…

Rust libraries also impose an - in my opinion - unacceptable burden to the open source ecosystem: https://www.debian.org/releases/trixie/release-notes/issues....

This makes me less safe rather than more. Note that there is a substantial double standard here, we could never in the name of safety impose this level of burden from C tooling side because maintainers would rightfully be very upset (even toggling a warning in the default set causes discussions). For the same reason it should be unacceptable to use Rust before this is fixed, but somehow the memory safety absolutists convinced many people that this is more important than everything else. (I also think memory safety is important, but I can't help but thinking that pushing for Rust is more harmful to me than good. )

Re: Why Is SQLite Coded In C

#214

Post by eesmith »

NobodyNada wrote: post #77
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.

It's interesting to consider (and the whole page is very well-reasoned), but I don't think that the argument holds up to scrutiny. If such an automatic bounds-check fails, then the program would have exhibited undefined behavior without that branch -- and UB is strictly worse than an unreachable branch that does something well-specified like aborting. A simple array access in C: arr[i] = 123; ...can be thought of as…

The 100% branch testing is on the compiled binary. To exempt unreachable assert branches, turn off assertions, compile, and test.

A more complex C program can have index range checking at a different place than the simple array access. The compiler's flow analysis isn't always able to confirm that the index is guaranteed to be checked. If it therefore adds a cautionary (and unneeded) range check, then this code branch can never be exercised, making the code no longer 100% branch tested.

Re: Why Is SQLite Coded In C

#215

Post by frumplestlatz »

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…

Calling it “SQLite-compatible” would be one thing. That’s not what they do. They describe it as “the evolution of SQLite”.

It’s absolutely inappropriate and appropriative.

They’ve been poor community members from the start when they publicized their one-sided spat with SQLite over their contribution policy.

The reality is that they are a VC-funded company focused on the “edge database” hypetrain that’s already dying out as it becomes clear that CAP theorem isn’t something you can just pretend doesn’t exist.

It’ll very likely be dead in a few years, but even if it’s not, a VC-funded project isn’t a replacement for SQLite. It would take incredibly unique advantages to shift literally the entire world away from SQLite.

It’s a new thing, not the next evolution of SQLite.

Re: Why Is SQLite Coded In C

#216

Post by weinzierl »

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/

Re: Why Is SQLite Coded In C

#217

Post by aw1621107 »

csande17 wrote: post #184
aw1621107 wrote: post #172

Earlier quoted context omitted.

> And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug. Is it getting brushed off as merely a compiler bug? At least if I'm thinking of the same bug as you [0] the discussion there seems to be more along the lines of the devs treating it as a "proper" language issue, not a compiler bug. At least as far as I can tell…

> Is it getting brushed off as merely a compiler bug? Yes, this thread contains an example: https://news.ycombinator.com/item?id=45587209 . (I linked the same bug you did in the comment that that's a reply to.) The Rust team may see this as a language design issue internally, and I'd be inclined to agree. Rust's outward-facing marketing does not reflect this view.

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

> Rust's outward-facing marketing does not reflect this view.

As above, perhaps I interpret the phrase "outward-facing marketing" differently than you do. I typically associate that (and "marketing" in general, in this context) with more official channels, whether that's official posts or posts by active devs in an official capacity.

Re: Why Is SQLite Coded In C

#218

Post by aw1621107 »

Ferret7446 wrote: post #149
hypeatei wrote: post #83

Earlier quoted context omitted.

I figured, but I guess I don't understand this argument then. SQLite as a project already spends a lot of time on quality so doing some `unsafe` blocks with a `// SAFETY:` comment doesn't seem unreasonable if they want to avoid the compiler inserting a panic branch for bounds checks.

If you put unsafe around almost all of your code (array indexing) aren't you better off just writing C?

Perhaps if the only thing you're doing is array indexing? Though I'm not sure that would apply in this particular case anyways.

Re: Why Is SQLite Coded In C

#219

Post by aw1621107 »

scuff3d wrote: post #191
mungaihaha wrote: post #170

Earlier quoted context omitted.

> But most of the other arguments they list can be picked apart and are only half true I'd like to see you pick the other arguments apart

> Other programming languages sometimes claim to be "as fast as C". But no other language claims to be faster than C for general-purpose programming, because none are. Not OP, And I'm not really arguing with the post, but this struck me as a really odd thing to include in the article. Of course nothing is going to be faster then C, because it compiles straight to machine code with no garbage collection. Literally any…

I think one additional factor that should be taken into account is the amount of effort required to achieve a given level of performance, as well as what extensions you're willing to accept. C with potentially non-portable constructs (intrinsics, inline assembly, etc.) and an unlimited amount of effort put into it provides a performance ceiling, but it's not inconceivable that other programming languages could achieve an equal level of performance with less effort, especially if you compare against plain standard C. Languages like ISPC that expose SIMD/parallelism in a more convenient manner is one example of this.

Another somewhat related example is Fortran and C, where one reason Fortran could perform better than C is the restrictions Fortran places on aliasing. In theory, one could use restrict in C to replicate these aliasing restrictions, but in practice restrict is used fairly sparingly, to the point that when Rust tried to enable its equivalent it had to back out the change multiple times because it kept exposing bugs in LLVM's optimizer.

Re: Why Is SQLite Coded In C

#220

Post by john_the_writer »

ziotom78 wrote: post #195
miohtama wrote: post #182

Earlier quoted context omitted.

You can find historical SQLite CVEs here https://www.sqlite.org/cves.html Note that although code matures the chances of C Human error bugs will never go to zero. We have some bad incidents like Heartbleed to show this.

Right, but I believe nobody can claim that Human error bugs go to zero for Rust code.

Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.
Post reply on HN