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

1–10 of 411 posts

Re: Why Is SQLite Coded In C

#2

Post by mikece »

The fact that a C library can easily be wrapped by just about any language is really useful. We're considering writing a library for generating a UUID (that contains a key and value) for reasons that make sense to us and I proposed writing this in C so we could simply wrap it as a library for all of the languages we use internally rather than having to re-implement it several times. Not sure if we'll actually build this library but if we do it will be in C (I did managed to get the "wrap it for each language" proposal pre-approved).

Re: Why Is SQLite Coded In C

#5

Post by Jtsummers »

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.

> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages.

From section "1.2 Compatibility". How easy is it to embed a library written in Zig in, say, a small embedded system where you may not be using Zig for the rest of the work?

Also, since you're the submitter, why did you change the title? It's just "Why is SQLite Coded in C", you added the "and not Rust" part.

Re: Why Is SQLite Coded In C

#6

Post by pm2222 »

These points strike me:

  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.

  Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.

  Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

Re: Why Is SQLite Coded In C

#7

Post by plainOldText »

Jtsummers wrote: post #5
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.

> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages. From section "1.2 Compatibility". How easy is it to embed a library written in Zig in, say, a small embedded system where you may not be using Zig for the rest of the work? Also, since you're the submitter, why did you change the title? It's just "Why is SQLite Coded in C", you added the "and not…

The article allocates the last section to explaining why Rust is not a good fit (yet) so I wanted the title to cover that part of the conversation since I believe it is meaningful. It illustrates the tradeoffs in software engineering.

Re: Why Is SQLite Coded In C

#8

Post by Jtsummers »

plainOldText wrote: post #7
Jtsummers wrote: post #5

Earlier quoted context omitted.

> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages. From section "1.2 Compatibility". How easy is it to embed a library written in Zig in, say, a small embedded system where you may not be using Zig for the rest of the work? Also, since you're the submitter, why did you change the title? It's just "Why is SQLite Coded in C", you added the "and not…

The article allocates the last section to explaining why Rust is not a good fit (yet) so I wanted the title to cover that part of the conversation since I believe it is meaningful. It illustrates the tradeoffs in software engineering.

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

From the site guidelines: https://news.ycombinator.com/newsguidelines.html

Re: Why Is SQLite Coded In C

#9

Post by rstuart4133 »

pm2222 wrote: post #6

These points strike me: 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. Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust ne…

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

This is annoying in Rust. To me array accesses aren't the most annoying, it's match{} branches that will never been invoked.

There is unreachable!() for such situations, and you would hope that:

    if array_access_out_of_bounds { unreachable!(); }
is recognised by the Rust tooling and just ignored. That's effectively the same as SQLite is doing now by not doing the check. But it isn't ignored by the tooling: unreachable!() is reported as a missed line. Then there is the test code coverage including the standard output by default, and you have to use regex's on path names to remove it.
Post reply on HN