HN Reader

previous discussion a few months ago: https://news.ycombinator.com/item?id=45584464

I believe this article is from a few years ago

The performance/memory security tradeoffs that C made made sense when computers were 100000 times slower and not connected to the internet but now when nearly all software is connected to the Internet it is a disaster.

Tittle should be "C is a Standard"

C is fast and maybe has predictable performance, but, for example, strcmp(), strlen(), strncmp() are not as fast (and also secure) as C++ std::string analogs, unless you don't help a bit by storing the string lengths.

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP.

If they are getting good results with C and without OOP, and people like the product, then those from outside the project shouldn't really have any say on it. It's their project.

I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old that is already so well tested and accessible on all sorts of obscure platforms, it makes little sense to rewrite, and the likely result would be more bugs, not less, at least in the short term.

All that said, some have found reasons to rewrite in Rust, and are currently working on that: https://turso.tech/blog/introducing-limbo-a-complete-rewrite...

> Rust needs a mechanism to recover gracefully from OOM errors.

Linus also brought this up: https://lkml.org/lkml/2021/4/14/1099

The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust.

I also think it's important to have really solid understandings (which can take a few decades I imagine) to understand the bounds of what Rust is good at. For example, I personally think it's unclear how good Rust can be for GUI applications.

Oh look. Something works. Lets not break it? How crazy is that?

I sometimes wonder if what happens is like this:

1. Have problem. Need higher level computer language. 2. Think about problem. 3. Solve problem - 'C' 4. Think about problems with 'C' 5. Attempt to fix problems with 'C' - get C++ 6. Think about problems with C & C++ 7. Get: Go, F#, Rust, Java, JavaScript, Python, PHP, ...other etc.

I tend to do this. The problem is obvious, that I do not repeat step #2. So then I move to the next step.

8. Thinking about how to fix C, C++, Go, F#, Rust, Java, JavaScript, Python, PHP, ...other is too hard. 9. Stop thinking.

I agree that C is best. I think Rust is actually a language with some severe downsides, despite having including some very good ideas and C having some real issues. But it will take a couple of years before one can discuss this rationally without being flamed at.

This submission title has been editorialized, contrary to the HN guidelines. The article title is actually "Why Is SQLite Coded In C".

Also, the article appears to be quite old, so the submission should have a year appended.

See also previous discussions, the last of which was only a few months ago: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

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

One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language.

But I don't see Rust ever going in such a direction. It seems fundamentally opposed to Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.

I've started using SQLite years ago for its use of a single file to store data. Along the way, I found more reasons to like it. Today, I discovered a new reason when I read this article.

I also noticed many software companies have been switching to SQLite for storing data. Audacity has switched from using hundreds of tiny audio files in multiple folders for a single recording to a single file using SQLite. I suspect it is the reliability that comes from sticking to C

The title is "Why Is SQLite Coded In C", not "C Is Best". The content is far more nuanced than this specific section title suggests.

"In a more complete build, SQLite also uses library routines like malloc() and free() and operating system interfaces for opening, reading, writing, and closing files."

Whoa. TIL there's a minimal build of SQLite that doesn't even need malloc() and free() !

Presumably for embedded devices. I'd love to see examples of that being used in the wild.

> But no other language claims to be faster than C for general-purpose programming, because none are.

The "faster than C for general-purpose programming" is a pretty woolly claim so I'm not entirely surprised nobody claims that, but equally I think to be sure that "because none are" would need some serious caveats to make it true.

In particular you're going to have to say you think it doesn't matter how much developer time is needed. A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.

Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).

And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.

> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM.

As someone who runs into this problem a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?

As an outsider when I read about Rust it seems like it is positioning itself as the language to rewrite things that already work.

It's just the simplistic first feeling of a language, in the same way I feel like Go is the language for Kubernetes/cloud/net servers, Ruby is for Rails, JS is the browser/bootcamp language, Python is Data Science and AI...

Sure, you get that safety but you are also throwing the stability that an old (and maintained) codebase has just for the sake of being patched to handle the presssure from the real world.

Maybe it's time Rust positions itself as something more than "the language of rewrites".

The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code.

Overall, it makes sense. C is a systems language, and a DB is a system abstraction. You shouldn't need to build a deep hierarchy of abstractions on top of C, just stick with the lego blocks you have.

If the project had started in 2016, maybe they would have gone for c++, which is a different beast from what it was pre-2011.

Similarly, you might write SQLite in Rust if you started today.

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

This is no longer true. Rust, Zig and likely others satisfy this requirements.

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

This is a major annoyance in the rust stdlib. Too many interfaces can panic (and not just in case of an OOM), and some of them don’t even document this.

> The C language is old and boring. It is a well-known and well-understood language.

This is such an under appreciated feature.

I'm tired of languages that just keep adding and adding to a language.

Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love.

Hell, I'd say the same is true for many libraries.

BTW, the study referred to in 1.2, which claims that SQLite was faster than the file system is not supported by the numbers in the study referenced:

https://github.com/chrisdavies/dbench

Makes a lot of sense for SQLite to be written in C. It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :)

The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.

From what they have written, the only other language that meets their requirement seems to be Ada:

1. Stability: Ada is an "old and boring" language (aka stable and reliable - the first standard for the language was issued in 1983 and created for the Defence industry) - https://learn.adacore.com/courses/intro-to-ada/chapters/intr...

2. Compatibility: Interoperability features is built-in, allowing you to create Ada libraries that can be used with other languages - https://piembsystech.com/interfacing-ada-programming-with-c-...

3. Embedded Programming: Ada has been designed for embedded programming and the language includes constructs for directly manipulating hardware, for example, and direct interaction with assembly language. - https://learn.adacore.com/courses/intro-to-embedded-sys-prog...

4. Ada supports processes / suites to comply with Branch coverage in ISO 26262 ( https://github.com/NVIDIA/spark-process ) and Decision coverage in DO-178C ( https://learn.adacore.com/booklets/adacore-technologies-for-... ).

5. Ada has features supporting memory safety to avoid many memory issues in the first place ( https://www.adacore.com/blog/memory-safety-in-ada-and-spark-... ) and using its exception handling and programming techniques (like pre-allocating "guard" memory) can allow Ada programs to tackle fringe OOM errors.

6. Performance: Ada is built for systems programming, is just as fast as C ( https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev... ), with the added bonus of "modern" programming features that can generate more "reliable" code

There's already attempted re-implementations of SQLite in Rust, so if it really is a good approach, time should tell.

https://turso.tech/blog/introducing-limbo-a-complete-rewrite...

Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong.

But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".

Actual title: Why Is SQLite Coded In C

What the post says is that you can do software engineering in C and be portable.

Well, can't argue with it. Ruby and Python are written mostly in C underneath.

Many try to replace C. All failed.

I'd love to see a language that could satisfy both high end needs and low need needs. I would not know how such a language would look though.

C is the first language where I actually felt like I was programming. After using C and assembly for a few projects, every other language started to feel extremely slow. Even now, when programming with TS, my mind always goes to legacy features that offer better performance at the nanosecond level.

> Recoding SQLite in Go is unlikely since Go hates assert()

I've heard it said you shouldn't use asserts in production code, but handle errors and exceptions instead? That said, can't you just 'if !condition() {panic...}' to simulate the behavior? Or are they talking about something specific about Golang?

> So, for example, Android applications written in Java are able to invoke SQLite (through an adaptor). Maybe it would have been more convenient for Android if SQLite had been coded in Java as that would make the interface simpler. However, on iPhone applications are coded in Objective-C or Swift, neither of which have the ability to call libraries written in Java. Thus, SQLite would be unusable on iPhones had it been written in Java.

This feels like they're responding to people asking for SQLite to be rewritten in Java. Who are these people?!

Ada is best.

No UB, strict types, contracts that can be formally proven, runtime checks, better (than phthreds) concurrency, certifiable.

It's bitch sometimes but you'll thank it after release.

2017 at least[1] but "This page was last updated on 2025-05-09 15:56:17Z."

[1] https://web.archive.org/web/20170701061906/https://sqlite.or...

The actual title is "Why Is SQLite Coded In C"

This makes sense with the quality and quantity of testing they do.

https://sqlite.org/testing.html

>As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.

I long to see an sq-rust project!

Given they added Section 2 and 3 in response to previous commentary: https://news.ycombinator.com/item?id=16585120

it seems rather stupid to take a sub-heading as the title.

DRH writing truth! People love to jump to Rust or C++.

C is like a classic car. It's cool and you might have fun with it, but if something goes wrong out there, there's a significant chance you'll end up in a very bad shape.

I can't imagine how writing C directly could possibly be better than using a language like Dafny and then generating C code.

Edit: Dafny: A verification language capable of enforcing invariants

No it's not. Arch is the best. https://wiki.archlinux.org/title/Arch_is_the_best

Absolutely.

What does “Go hates assert()” mean?

i haven't seen any rust projects yet that maximize embeddability, portability, space and transparency. maybe an argument could be made for the linux kernel stuff, but nothing like a sqlite that gets compiled and included in a million things on a million platforms ranging from high level interpreter wrappers on general purpose computers to teeny microcontrollers where the operating system is a library or some jump targets in rom.

that said, just because c is best for sqlite today, doesn't mean c is best for you or what you're trying to do.

C3 is bester?

C is good

I'm a little surprised they're at all open to a rewrite in Rust:

> All that said, it is possible that SQLite might one day be recoded in Rust.

...followed by a list of reasons why they won't do it now. I think the first one ("Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.") is no longer valid (particularly for software that doesn't need async and has few dependencies), but the other ones probably still are.

I write Rust code and prefer to minimize non-Rust dependencies, but SQLite is the non-Rust dependency I mind the least for two reasons:

* It's so fast and easy to compile: just use the `rusqlite` crate with feature `bundled`. It builds the SQLite "amalgamation" (its entire code basically concatenated into a single .c file). No need to have bazel or cmake or whatever installed, no weird library dependency chains, etc.

* It's so well-tested that the unsafety of the language doesn't bother me that much. 100% machine branch coverage is amazing.

...at what it does, couldn't agree more.

https://github.com/codr7/hacktical-c

I love C and Assembly and I'm impressed by the things people can build in those languages and often (not always) I can understand the code written in it. It's also true that code written in it is available to every other language. For that I'm very happy, as I'm mostly working in higher level languages that can call things like sqlite.

Just imagine if all of Chromium was written in C and used simpler tools like GNU Make and Git for it's projects.

WRONG!

Plain and simple C is, by far, one of the current _LESS WORSE_ performant alternatives which can be used, actually, from low level to large applications.

C syntax is already waaaaay to rich and complex (and ISO is a bit too much pushing feature creep over 5/10 years cycles).

no, triples is best!

.. one of the safe languages like.. Go.. o_O

C is considered harmful. They should rewrite it in Rust.

Well they don’t have to wait for Rust in the way they said - they’ve already been forked by Turso which has been moving along for a while now. I wouldn’t mind hearing from them how that’s been going.

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

Doesn't the language compiler write the code that checks if the array access is in-bounds? Why would you need to test the compiler's code?

*C-API is the best.

As a language, it's too basic. Almost every C projects try to mimic what C++ already has.

I've often said (at least half jokingly) - C for systems programming, Javascript for everything else!

This artical makes the case for C as a low level language, I then offer Javascript as a functional-ish language for manipulating domain model data structures on the top.

1. This isn't a 2025 article, it's much older but it received some updates in 2025.

2. Ada is about as old as C so should have been considered as a possible safe language. It's safer than Rust in my opinion. GNAT was released in 1995 while SQLite is from 2000, so it was a possibility. C++ was also around: still unsafe, though less so than C.

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

I don't think they thought about this too much. In the C code are they testing the "branch" into Undefined Behaviour?

The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.

Given SQLite's amazing battery of test code, it seems like it would be valuable, illuminating, and not too difficult to write a test implementation in Rust. Can you get the Rust implementation to pass the test suite? Either answer to that question would be interesting.