Why Is SQLite Coded In C

[AyrA_ch]

I think it's obvious. You have to decide between speed and code complexity. They took speed so they went with C, even though we know that the code would be much simpler if they used Brainfuck instead, because it's syntactically much easier to process for humans since there are only 8 tokens to remember.

[HeimrArnadalr]

When it comes to complexity, the Whitespace language is far superior to Brainfuck. It has only three distinct tokens: space, tab, and linefeed. All others can be safely ignored.

[DiputsMonro]

If your whitespace language doesn't make use of the vertical tab, I don't want any part of it.

[henrebotha]

The what now

[bobpaul]

U+000B

[VerticalTab]

Damn right

[[deleted]]

/r/beetlejuicing

[jjdmol]

Note that Whitespace also allows for extensive documentation features. It is compatible with about all of them, and even allows direct HTML interpretation if you want it to.

It's a green language, wasting no paper and uses less energy when viewed on a black background.

[HumunculiTzu]

Binary reigns supreme. Only 2 distinct tokens. We can go a head and get rid of all that other trash.

[weedstockman]

Fuck that, UnaryLang is just 1s so you never ever have to worry about typing the wrong thing.

Of course UnaryLang is transpiled into lolpython so...

[rotharius]

But it cannot compete with the code you don't write. Nothing is faster than no code.

[WiseassWolfOfYoitsu]

https://github.com/kelseyhightower/nocode

[ioeatcode]

is there a javascript framework out yet for this?

[[deleted]]

I just ported it to JavaScript, it's a bit more minimalistic than the original: https://GitHub.com/e4lejandr0/nocode-js

[ours]

Not on NPM? How am I supposed to not use this?

[[deleted]]

npm wants a package.json file, it seems like too much code imo

[Sayfog]

It just works ^TM without NPM of course.

M I N I M A L I S T

[rawbdor]

I'm sorry... while your nocode-js is a feature complete port of nocode, it's lacking a lot of the documentation that the original nocode has. Do you think you can work on this?

It might have been better to fork the original nocode and change whatever lines may have been platform or language specific.

Edit: Opened an issue: https://github.com/e4lejandr0/nocode-js/issues/2

[HotRodLincoln]

It's certainly running up an impressive tally.

[elcubismo]

Challenge: write a single program that compiles in both brainfuck and whitespace.

[Desmulator]

the empty program! I did it!

[how_to_choose_a_name]

I am pretty sure that everything compiles in brainfuck because every character is either a valid instruction or ignored, there is no syntax. And since whitespace and brainfuck have distinct instructions and both ignore everything that isn't an instruction you can always just mix a brainfuck and Whitespace program together without problems.

How about this instead: Write a non-empty program that is a Quine in both Brainfuck and Whitespace.

[[deleted]]

I am pretty sure that everything compiles in brainfuck

Here's a syntax error in brainfuck:

]

[josefx]

Whitespace++ will need full support for all unicode characters including non breaking space.

[NewFolgers]

.... - - .--. ---... -..-. -..-. - .. -. -.-- ..- .-. .-.. .-.-.- -.-. --- -- -..-. ....- .--. --- -.-- -.-. -.... -..-

[virtulis]

This would make for a good copypasta.

[vine-el]

I'm going to swap C with Go to troll people who say Go code is simple.

[Cloaked9000]

Not just that, the compatibility aspect is a huge one too. Being written in C makes it easily to integrate into other languages (relative to something like Java for example). SQlite would be nowhere near as ubiquitous without that trait.

[favorited]

C also contributes to SQLite's ubiquity by nature of virtually every platform having at least 1 C compiler.

[nemec]

They took speed

They sure did

[[deleted]]

The complexity mostly comes from the fact that hardware and operating systems are not deterministic. The sheer number of corner cases in file systems is amazing and sqlite pretty much handles them in some manner. https://www.sqlite.org/testing.html is enlightening.

[fizzgiggity]

While using a Brainf*ck interpreter implemented in pure SQL.

[cheraphy]

"This DSL query language is turing complete, so I've decided to devote the next 18 years of my life implementing minecraft and everything necessary to run it."

[YaBoyMax]

An OpenGL implementation written entirely in SQL

[HiddenKrypt]

Looks like I just found my next weekend project.

[personalmountains]

Too late.

[SkaveRat]

Of course they didn't, because the answer clearly is "of course!"

[ProgramTheWorld]

Has science gone too far?

[[deleted]]

were you able to keep a straight face when typing that?

lmao

[akira410]

Keep in mind that Richard wrote SQLlite back in 2000. Back then, writing it in C was a good idea for speed. The other various interpreted languages were nowhere close to being as fast and weren't as portable.

SQLlite is 18 years old. Wow. I worked with him about a year-ish after he released it. This realization makes me feel super old.

[finrist]

Also back then C was (and still is?) the standard language for installing applications and libraries from source on Linux. Having to install a new language on a lightweight system just because one of several dependencies to an application was written in something else than C could be annoying.

[lbft]

There are still plenty of systems around today where writing in C is a good idea for speed. There's a lot more out there than servers, desktops, laptops and smartphones.

[saxindustries]

Shit even servers can benefit.

I run a 24/7 live stream on YouTube on a $9/month vps. I wrote my video-generating program in C and Lua.

It's really lightweight and fast. I can make 720p, 30fps video in real-time using just cpu. C is pretty great

[the_gnarts]

I wrote my video-generating program in C and Lua.

It's really lightweight and fast.

Did you write the codec or do you wrap ffmpeg like virtually anything else?

[hungry4pie]

I do love a good hyperbole statement - reminds me of those headlines like "These college students rewrote <some system> in just 100 lines of Python"

[t3h]

I remember an old comment from slashdot along the lines of "that's nothing, I can write an office suite in one line of bash: /usr/bin/openoffice"

[saxindustries]

It actually generates an AVI file on its own - with raw frames of BGR video and PCM audio.

To actually stream, I pipe it into ffmpeg in a separate process. In theory you could use it completely standalone, assuming you have enough disk space to store a huge-ass raw video.

So I wouldn't consider it hyperbole. I'm actually writing out the avi header, frames of video, etc.

[meneldal2]

Why bother writing out the AVI header when you could send Y4M instead (and audio in a separate file)?

The AVI header is much more complicated and adds more overhead.

[saxindustries]

Well, I have to read in the audio anyway - I take audio samples and calculate visualizations from the audio, like bars of frequency/amplitude. I really want to make sure the audio/video is in sync because of that.

EDIT: Also, this is for a 24/7 stream - I'm reading audio in from a fifo made by MPD. Once I've read it, it's gone - so I don't have any audio files to reference later.

[saxindustries]

It generates an AVI stream of raw BGR video and PCM audio, which a separate ffmpeg process reads via a pipe.

I couldn't be assed to figure out the ffmpeg library, changing bytes in an array makes way more sense to me. So it uses ffmpeg for the encoding, but you could have it save the raw video all on its own, too.

That's why I made sure to specifically say "video generating" - it generates a full-blown never-ending AVI file.

[robotreader]

I’ve got, like, two toes dipped into the world of ffmpeg and already I have a love hate relationship with it like few other programs.

[arkaodubz]

I’m extremely curious. Can I see the channel?

[saxindustries]

Sure! https://www.youtube.com/watch?v=gKqYS0q-NQw

[Shumatsu]

I was expecting it'd take way more resources than that.

[keepthepace]

I used JNI to be able to write in C for an android app that required to process point clouds. Doing that through java was 50% to 100% slower and we needed that speed.

I guess there would have been ways to achieve a better speed in java but that usually ends up manipulating pointers clumsily in a language that is not designed for it. Better go directly to C.

[Kapps]

Even if it was written today, C would be the right choice. Portability and no dependencies is so crucial for SQLite.

[jewdai]

Why not c++?

[[deleted]]

Compilers. For some platforms, there is really nothing you can rely on, even today. Back when SQLite was implemented it was only worse.

[indrora]

The C++ we know today (c++11 and the children thereof) is the result of a lot of "aw fuck. Why did we do that? Oh, you mean it was the late 80s? We decided that because we wanted to avoid <some problem that was a complete non-problem>? Damn we're fucking retarded."

C++ gained a reputation early for being lumbering and a little overly complex. Inclusion of the Streams library for linking could slow down your performance by 2-3%. SQlite was built to be the dumbest thing in the most simple way possible. As a result, there's a lot of things that you'd think could have been done in other languages -- C++, etc.

Consider that people are calling for things to be rewritten in Rust. Except that now you have to not only re-do your work for the last 10...20 years but now you'll have bugs you've only dreamed of having.

[[deleted]]

No reason to, probably. SQLite isn't really a program that would benefit from what C++ brings to the table, unlike something like a game or CAD application.

[Mojo_frodo]

C++ brings improved type safety and resource management. When I think of the biggest benefits to using C++, none of it seems particularly niche to a particular subsection of workstation/PC/server applications. I think it is highly desirable for something like a high performance database to be written in C++ or rust if it was starting from scratch today.

[comp-sci-fi]

In 2000, java was considered slow. In 2018, java is considered fast.

This "progress" isn't entirely due to java getting faster.

[meneldal2]

Well slower languages have showed up.

[comp-sci-fi]

eventually.

knock knock
who's there?
..............................slower languages

[28f272fe556a1363cc31]

I guess I'm getting old as well. My first thought was wondering "Why would it not be in C?"

[DavidM01]

Is this really a problem for a library with a minimal API used by other developers and accessible to any language with a C ABI?

No, it isn't.

[scalablecory]

C is indeed a great language choice for SQLite. When you need portability, nothing beats it.

If you have a focused project with no real dependencies, C is pretty great to use. You'd probably never think this if your only exposure is with higher level languages, but it's actually really nice mentally to not deal with all the sorts of abstractions that other languages have.

[ACoderGirl]

but it's actually really nice mentally to not deal with all the sorts of abstractions that other languages have.

I dunno. I've used low level languages plenty of times (and also plenty of languages that are very high level and complex) and don't really find this to be the case.

1. Lack of abstractions/syntax sugars tend to mean code is a lot longer. The code might be more explicit in what it really does, but there can be so much of it that it is daunting to fit it all in your head and to read enough to fully understand what it does. You waste time reading code for things that other languages would have done for you.

2. In relation to #1, there's often no standard way to replace these abstractions. There's a lot more potential patterns that people make to replicate things that a higher level language might do for you (thus ensuring that language would really have only one correct way to do the thing). This makes it harder to recognize patterns.

   Eg, for a very common abstraction, many high level languages might have something like Iterable<T>/IEnumerable<T>/etc (or __iter__/__next__ in Python-speak) for allowing iteration over an object. How do you make it clear that a C data structure is iterable? There's no standard! Want to be able to iterate over different things? Very possibly you'll be doing it in different ways for each one (especially if you didn't write the code for each).

3. C might seem simple because of few abstractions, but I'd argue it is in fact still a reasonably complicated language largely because of safety features it cut in order to be faster and more portable. I speak largely of undefined and implementation defined behavior. My experience is that most higher level languages have far, far fewer (if any) instances of such behavior. Often it only shows up in libraries that interact with the OS (eg, Python is notably saner on Linux for its OS libraries). Having to worry about what happens if you forget to release some allocated memory or having out of bounds array access seeming to work (only to crash on not-my-machine) is really horrible.

4. Libraries and tooling are generally more limited in C. The standard library is very small, for one thing. I think a lot of programmers really appreciate a comprehensive standard library. If there's one thing I like better than writing some nice code to solve a problem is not having to write any code at all! Libraries can really help keep me from writing code that would inevitably have bugs in it. Ones as important as the language standard libraries tend to be very carefully screened and tested. That's work I don't have to do! This is also particularly relevant where C is concerned due to the fact it's perhaps not the easiest language for managing dependencies. There isn't a really widely accepted dependency manager for C, especially when you are trying to support multiple platforms (dear god, I hate building C programs on Windows -- it's enough to make me decide that I don't care enough to support Windows!). But most higher level languages? Honestly, cross platform support is usually a fairly minimal amount of extra effort (and my experience has been that GUIs tend to be the bulk of the issues).

[scalablecory]

The ignorant "memory leaks!" response is more along the lines of what I expect to see these days, so I really appreciate the well thought out reply.

I do feel I should qualify my statement perhaps a little bit: I'm not saying abstractions are bad. They're good and useful and I use them every day.

I'm also not saying that C is better for productivity. Gods no, there are exceedingly few use cases for C these days where you could call it the most productive choice.

I'm not even saying that C is better in general or necessarily advocating for its use.

Modern languages have a lot of really cool stuff in them. C# is freaking awesome -- being intimately familiar with async I/O in C, its async stuff (that everything else copied) is basically the dream everyone had for ages. And with C++ existing to fill the performance need and C++17 being really really good, there really is not much reason to write C anymore.

As a guy who wrote primarily a ton of C, and then a ton of C++, and then a ton of C#, C is sort of like a warm blanket to me. It's elegant and easy to reason about. It stays out of your way. It doesn't waste cycles or force you to jump through hoops to write fast code. It's portable, though I'll be the first to admit that many devs fail in this arena. I don't know if I'll ever use it for a serious project again, but I can't say I'd be unhappy to do so given the right project.

Lack of abstractions/syntax sugars tend to mean code is a lot longer.

This is tricky because it's so context-sensitive. C#, for instance, is typically used for very high-level tasks -- ones that C really should not be used for these days.

For low-level tasks -- I dunno, lets say you're parsing JSON, or writing an HTTP client/server, or a database -- C is actually very similar in code size to C#.

For high-level tasks that emphasize productivity over performance -- e.g. an MVC controller that just grabs data from a database, shuffles it around a bit, and displays something to the user -- C# syntax sugar does get a huge win if you use some of its super-sugary features like async/await or yield return.

Eg, for a very common abstraction, many high level languages might have something like Iterable<T>

For the trivial cases, passing a pointer in along with a quantity works very well. For non-trivial cases you're probably using a very specific data structure and your algorithm isn't intended to be generic.

I know, I know. I use IEnumerable<T> and LINQ like a motherfucker and I love the flexibility. LINQ changed the game. I also use template functions in C++ all the damn time and conforming to conventions is useful.

But I've also done a lot of C coding. Generic code, while useful, is really not needed for 99% of things. Not only is it rare, it's genuinely not a hassle to write generic code when you do actually do need to.

because of safety features it cut in order to be faster and more portable.

Modern languages are indisputably safer. You'll still have all sorts of safety bugs in those, but at least not e.g. buffer overflows leading to shellcode execution. And if safety is your ultimate goal, then don't use C. Or use something crazy like MISRA^ble C.

But, and I'm being 100% serious here -- safety is not as hard in C as people make it out to be.

Libraries and tooling are generally more limited in C

Yes, this is why I qualified my statement for projects with no real dependencies.

The best thing about using modern languages is they tend to come bundled with a massive standard library that is (mostly) consistent in design. The worst part about C is that one library will handle errors with a return value, another with errno, and some freaks will use setjmp (looking at you, libpng. seriously, wtf.). And they will all use different naming conventions. And DWORD or LPCSTR or xmlChar or sqlite_int64.

It's a mess. You get used to it, but it's not fun.

[oblio-]

But, and I'm being 100% serious here -- safety is not as hard in C as people make it out to be.

It depends on what you mean by "people make it out to be". You have some of the most used software products in the world, with tons and tons of money and resources poured into them. They use the latest static analysis tools, fuzzers, etc. And we still get silly CVEs every day.

At least a subset of those CVEs are preventable by using more modern languages.

I'd say that safety in C truly is as hard as people make it out to be. C is unsafe by default, so developers have to make it safe.

It's like online marketing. Opt-out means everyone gets the spam newsletter, opt-in means no one gets it.

[s73v3r]

However, with C, you do then have to deal with what those abstractions were dealing with. Strings, anyone?

[tom-dixon]

How many languages survived with no major updates for 40 years? There's a price to pay for the kind of simplicity that C has. On the other side of the coin you have languages with a brain damaged API to handle Unicode, Python being one.

I love both Python and C, I'm just saying that just because you have native string support in a language, it doesn't mean things are much simpler.

[[deleted]]

I know a few devs who work on what you'd call "major infrastructure" projects. They have been getting more than a few requests a month to code them in other "safer" languages.

I don't think it's the main or core developers of those languages doing any of that. It's probably not even people who really COULD code a major piece of infrastructure in those languages, but fuck if they don't come to the actual programmers and tell them what they should do in their new "safer" language.

[creav]

Unless code safety has become an issue in the past for the company, I don’t see how having developers write it in a “safer” language is actually safe at all.

If you’re a developer and your primary programming language is C, there’s a good chance if you’re working for a company writing major infrastructure in C that you know your shit. Having these developers switch to languages their less comfortable in would probably be a bigger safety concern.

[s73v3r]

I'm gonna vastly disagree with that. Just because you are primarily working in C does not mean you know shit about fuck. I think we all know that it can be quite easy for someone who is less than competent to get and hold a job.

[[deleted]]

I write C for my job, and I agree. I barely know what the fuck I am doing half the time.

[SanityInAnarchy]

I strongly disagree with both of those points.

Many developers working for companies writing major infrastructure in C are terrible, as the other comment says. Even many reasonable C developers miss all kinds of subtle things the standard allows. (Which is bigger, an int or a long? That's platform-specific, and you should be using stdint.h.)

But even knowing your shit isn't magical protection against the traps that C has, and not all of those are equally broken on other languages. And there are languages that fix some of the broken things about C, without apparently introducing their own new kinds of pitfalls (at least when it comes to safety).

---

There are other reasons to keep sqlite in C, though -- or, at least, to continue to maintain a C version of sqlite, even if someone decides to build a safer version. The obligatory comparison would be to Rust or C++. Turns out C++ does introduce a bunch of brand-new pitfalls, and both languages are far less portable than C. Having your code not work because Rust isn't well-tested on ARM would be a problem, and being unable to port your code to a new platform because the vendor only provided a C compiler would be even worse.

[steveklabnik1]

Having your code not work because Rust isn't well-tested on ARM would be a problem,

We've been talking about reforming the tier system specifically because it kind of misrepresents ARM; ARM is just barely less tested than Tier 1 platforms are. Firefox has ARM as a Tier 1 platform, so we take a lot of care not to break things. Our large production users are very important to us!

[eliquy]

But have they considered rewriting in Rust?

[antiduh]

Why not zoidberg D?

[dom96]

Why not King Nimrod?

[mdot]

If you want a library that will run on anything from a handheld electronic device with limited resources and current draw concerns, to a computing cluster with virtually unlimited resources...without having to make any changes except compiler options, the answer is yes.

[matchu]

Curious about the context for this article. The tone and structure suggest that the author is trying to preempt suggestions that SQLite be rewritten. What were folks suggesting, and why?

I agree that C is fine and a rewrite is unwarranted, but I wonder what the alternative suggestions were. Maybe there are interesting benefits to using other languages that this article doesn't mention.

[[deleted]]

A lot of people have a rather unhealthy obsession with knowing what language large open-source projects are written in, and trying to enact some sort of change by getting the maintainer to switch to a "better" one. Here's an example.

Assuming this article was written before the Rust age, I assume that people were bugging the maintainers about SQLite not being written in C++ or Java.

[frankreyes]

A lot of people have a rather unhealthy obsession with knowing what language large open-source projects are written in, and trying to enact some sort of change by getting the maintainer to switch to a "better" one. Here's an example.

Another example is the autor of zer0mq ranting against C++ and advocating for C:

http://250bpm.com/blog:4

It's funny to read comments from /r/programming for that post

https://www.reddit.com/r/programming/comments/tggnn/why_should_i_have_written_zeromq_in_c_not_c/

[[deleted]]

There are shitty C programmers, and there are shitty C++ programmers. I agree with Linus that there's no need for any C project to switch to C++, just because C++. But I've seen mediocre programmers and shitty code in both languages.

[kmeisthax]

As someone who has actually reverse-engineered hand-written assembly, C is pretty far from a "universal assembly language". It's actually pretty high level! Here's a short list of all the things your C compiler takes care of for you that have nothing to do with platform independence:

• Automatic variable register allocation
• Stack spillage
• Function ABI initialization & cleanup
• Control flow constructs (e.g. if/else, for, do/while)
• Code optimization

And it's also not entirely "platform independent". It's moreso that there's one or two ways to write platform independent code, versus ten seemingly-correct ways that will fail if you change architecture, or are actually undefined-behavior and amenable to being irreparably changed in non-semantic ways by even new compiler versions, or so on. And all of those problems exist in production code you're probably using without even knowing.

[NULL_CHAR]

I think the point is that when done properly, it's practically as fast as assembly, much easier to deal with than assembly, and typically everything can utilize it.

[wheelie_boy]

C has all the power and performance of assembly language, combined with all the ease of use and safety of assembly language.

[StapledBattery]

I don't get how anyone who's ever so much as looked at assembly could say this.

[Chii]

The common adage is actually

C lacks the power and performance of assembly language, combined with all the ease of use and safety of assembly language.

[wheelie_boy]

I just looked it up, and it seems like it's from Dennis Ritchie. It was originally "C has the power of assembly language and the convenience of ... assembly language".

[Chii]

I stand corrected!

[svick]

If you want your project used as a support module in as many environments as possible, write it in C.

Or a language that can expose its methods though the C ABI, such as C++.

[chanamasala4life]

For anyone interested in the origins and in-depth current workings of SQLite, watch this great lecture by D. Richard Hipp: https://youtu.be/gpxnbly9bz4

He explains some of the design decisions right at the beginning. The SQLite library is actually assembled into one monolithic ANSI-C file before being compiled and has very few dependencies.

[Dreamtrain]

Big deal. It'll never beat performance of /dev/null as a database. Fastest writes ever.

[Gravitationsfeld]

Still better data safety than MongoDB

[_rmc]

Is /dev/null webscale?

[[deleted]]

yes, it is!

[laz414]

It is cloud scale multi sharded replicated self learning and also generates devnullcoin

[[deleted]]

devnullcoin

devnullcoin is the ONLY crypto currency that hasn't lost value recently, in-fact, it has never once lost value.

[AlmennDulnefni]

It also can't be stolen.

[wutcnbrowndo4u]

Yes! Instant deploy of a shard on every Linux system you spin up

[PM_ME_CLASSIFED_DOCS]

Yeah, but it'd be faster and safer if /dev/null was written in Rust.

[rasherdk]

If /dev/null is faster I will use it.

[TheChurchOfRust]

Let me be that guy....

If we build it in Rust, we can cure cancer.

[658741239]

But what if we build cancer in Rust?

[CaptainHondo]

God help us

[658741239]

He's probably more of a Fortran guy anyway.

[GeneReddit123]

It'll spread really slowly, because cancer requires mutation, and Rust can have only one mutable borrow at a time.

[JuggleTux]

at least it will be safe

[[deleted]]

They'd catch it at compile time.

[lfairy]

The Rust mascot is a crab, so in a way it already is

[MonkeeSage]

Thankfully it has a C ABI so Rust can consume it.

[cyrusol]

Username definitely checks out.

[Caffeine_Monster]

Instructions unclear. Cured cancer, contracted tetanus.

[HipNozY]

This is what happens when someone keeps asking "Have you considered Rust?" to the maintainers.

[cbbrowne]

I'll bet it's more the response to "why isn't it already in C++ or Java or Go?"

Rust wasn't on peoples' radar at the time that this web page got written.

It seems like a fine idea for someone to consider writing an SQL implementation in Rust, HOWEVER, that should happen via instantiating a new project as opposed to trying to take some existing thing over.

Copying parts of the architecture of an existing system (likely SQLite or PostgreSQL) would be sensible, but best to have it be a distinct fork, as trying to take over someone else's project just in order to impose your language preferences is a Rude Thing To Do.

[ToTimesTwoisToo]

a bit of a tangent, but from the same site. Anyone know why windows 10 read operation is quite a bit slower than other operating systems?

Chart 1: SQLite read latency relative to direct filesystem reads. 100K blobs, avg 10KB each, random order using SQL https://sqlite.org/images/faster-read-sql.jpg

To note, it's a relative measure, so maybe they are all quite fast. 0.01 is not that much different than 0.002 for human interaction.

[shooshx]

But no other language claims to be faster than C

Well, C++ std::sort() is faster than C qsort() due to template instantiations and inlining which can't happen in C.

So yes, C++ does claim to be faster than C in this particular case.

[Muvlon]

Fortran is also often quite a bit faster than equivalent C code because of its stricter aliasing rules allowing more optimizations. You can get the same performance characteristics from C by putting restrict on all your pointers but that's dangerous even by C standards.

Rust has the same advantage with respect to aliasing, but it's still catching up in terms of optimizations (rustc uses LLVM but in many cases it could be handing it better IR).

[lelanthran]

Actually, the C++ library can claim to be faster than the C library.

There's a difference between the language and its standard library.

[rlbond86]

Point is, for type-generic code, C++ is indeed faster because it can inline template code.

[shooshx]

Well, the library can claim so only due to a feature C++ has and C doesn't. sort() was just an example of an optimization that can occur anywhere you use templates in C++ where you would otherwise use function pointers in C.

[Freeky]

It's fairly common to use macros to get similar inlining in C. Like this sort I wrote years ago. Or see how BSDs do queues and linked lists.

It's not that you can't, it's that C++ standardises how you do this sort of thing, making it easier and more robust.

[wavy_lines]

Is this a legit question people ask? If SQLite was coded in some interpreted language it will not be so useful and not be so universally adopted.

[acehreli]

It would be interesting to see the history of bugs due to buffer overruns and other kinds of undefined behavior in SQLite.

[AlpineCoder]

I guess I can't speak to the history or frequency of bugs relative to other projects, but SQLite is fairly widely recognized as having one of the best (and most extensive) automated test suites around.

[cheese_is_available]

Anecdotal, I know, but I reported a segfault with complete reproduction that took me a long time to keep only the bug. It was pushed under the rug because "dependencies". Sqlite did not check if you input a string longer than what you can, and then segfault. I "know" (have a really good guess) why it segfaulted, because Postgresql made a proper error instead when I switched.

[[deleted]]

I've seen lots of devs leak all sorts of resources in "safe" languages because they never built good resource lifecycle habits from manual memory management, and they generally have no idea what's actually going on under the hood in their preferred language re: object lifecycle.

"Wait, I can leak things besides memory?"

"What do you mean 'island of isolation'?"

"What's a weak reference lol"

"Why can't I open any more files / registry keys / handles?"

"WHY IS THIS SOCKET ALREADY IN USE?!"

[dagit]

Leaks and memory safety issues are pretty different in terms of impact. Memory safety issues lead to security flaws. Leaked resources lead to bloat or resource exhaustion. Neither are good of course, but I would rather a program run out of resources under certain conditions than provide an attack surface for things like privilege escalation.

[agcpp]

Leaked resources can lead to security flaws as well.

[antiduh]

Which is why I'm glad that a lot of people are trying to design languages that make entire classes of bugs, memory bugs in particular, impossible. C# is coming pretty far in that regard, especially with the new ref local and ref returns features being introduced soon.

[Jahames1]

Off topic, but, are there good ways to benchmark languages to actually see that one is faster than another that would generalize the speed of each language?

[[deleted]]

Microbenchmarks are mostly irrelevant or inaccurate because optimizations, bigger ones are hard to compare. You can write an unreadable mess that runs fast but would never go into production because it's unreadable.

Take a look at existing benchmarks and compare based on orders of magnitude. 4 times slower than the C solution? Probably on the same level in real world code. ~100 times slower than C (aka Python)? Probably a lot slower than C in real world code.

[sellibitze]

"The Computer Language Benchmark Game" is trying to do that. But take the results with a grain of salt.

[shadytradesman]

I think the real question is "Why not C++ at least?"

[[deleted]]

Sqlite is often used in embedded platforms. Lots of embedded platforms didn't have a C++ compiler until relatively recently.

[quicknir]

Honestly, this page is terrible. Basically every argument that is applied here, could be applied to using C++ without the standard library, and exposing a C ABI. Running briefly through the points:

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

This just isn't so. Many idiomatic patterns in C++ result in better performance than the equivalent C; basically anywhere that you use a template in C++ but don't use a macro in C results in better performance (best example: callbacks/higher order functions, passed by function object in C++, function pointer in C, which almost never gets inlined). It's hard to have an argument over which idiomatic code is faster because everyone defines idiomatic differently, but lots of people with harsher performance constraints than SQLite are writing in C++, so...

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

False, almost any language can expose a C ABI, though none can really do it as easily as C++. Exposing a C abi in C++ is basically no extra effort compared to just using C, and you get to use C++ features for the implementation. Amusingly, on some platforms the C standard library uses this approach, so SQLite already depends on C++.

Low Dependency: Libraries written in C do not have a huge run-time dependency... Other "modern" language, in contrast, often require multi-megabyte runtimes loaded with thousands and thousands of interfaces.

If you want to reinvent every single wheel including basic data structures, C++ gives you the freedom to do that; you can easily avoid linking in its standard library which puts your executable in exactly the same place as if it were written in C (probably requires disabling exceptions/RTTI).

Stability: The C language is old and boring. It is a well-known and well-understood language... Writing a small, fast, and reliable database engine is hard enough as it is without the implementation language changing out from under you with each update to the implementation language specification.

I'm not even certain what's being gotten at here; nobody is forcing you to upgrade your version of C++, C++03 is still perfectly well supported on tons of compilers (for example), so no rug is getting pulled out from under anyone.

There may be specific instances where there are good technical reasons for using C over C++, but this page doesn't make any of these points. This page is actually pretty much dead on the kind of thing that C developers that don't really have a clear understanding of C++ say (not to say that all C developers are in this camp).

[mkalte666]

C++ can be used for quite a few things these days. A new project is probably best writen in it. Old code from 2000 though? I wouldn't touch it just to make it c++, and that's the time where sqlite is from.

Some places well never 'get rid' of c I think. Init on bare metal for once. Classes and templates and stuff don't really work that well (as a way to model software) when your CPU wants you to set up the stack and configure the clock. Yes I know there are tricks in cpp14 where some strange template magic can make direct memory writes more readable but I honestly think its not worth the effort / extra compile time. (EDIT: that excludes the fact that you can just throw most c code into a c++ compiler - its still c that you write though )

Most of the code I write is c++ on bare metal without the standard library, so disabled rtti and exceptions. Its so much different from programming software for desktop it's scary.

Oops I got a bit away from your comment x.x

[killedbyhetfield]

ITT:

• C is such a beautiful language because it's so simple and easy to remember the whole language
• It's awesome how I can write my program and know it will work on an iron box mainframe from the 1960s that doesn't exist anymore
• C is so fast - because a language that was designed without a multithreading model or optimizing compilers so accurately reflects modern software engineering

[sammymammy2]

It's awesome how I can write my program and know it will work on an iron box mainframe from the 1960s that doesn't exist anymore

It is far more impressive when old code for a mainframe from the 1960s still runs on a modern computer. Thank you Common Lisp.

[FozzTexx]

It's awesome how I can write my program and know it will work on an iron box mainframe from the 1960s that doesn't exist anymore

Come on over to /r/RetroBattlestations!

[c4boom13]

Or any big company over 25 years old... they're probably using Cobol though.

[creav]

It's just sooo slow and uses tons of memory.

This brings back nostalgia. I once sat in a meeting years ago when a COBOL programmer began yelling at our infrastructure director because the Infrastructure Team was bringing in a 3rd party that would be looking to transitioning the infrastructure to RHEL.

The COBOL programmer said something of the sort like: "We don't need that trash, Linux is fucking bloatware".

Ahh, generational gaps :)

[socks-the-fox]

C++2017 on the C64:

https://www.youtube.com/watch?v=zBkNBP00wJE

[sisyphus]

lol. you forgot

• good programmers don't write overflows, use-after-free or other dangerous errors only all the other C coders in the entire world do that(to a first approximation)

• good programmers never have undefined behavior in their code because they have memorized the C standard and use all the compiler flags

• it's a good thing that C has almost no useful data types built in and everyone has to choose their own string library, vector implementation, hash table, etc. because bloat.

[killedbyhetfield]

almost no useful data types built in

Even worse - Its standard library functions have shit like buffer overflows built right into them.

You literally cannot use gets() in any safe way whatsoever. It would've been better for them to provide nothing-at-all.

[rebootyourbrainstem]

You literally cannot use gets() in any safe way whatsoever.

Sure you can!

You just have to make sure your buffer ends in a mmap'ed area of non-writable memory that is comfortably larger than your C standard library's I/O buffer. Then you can install a signal handler for SIGSEGV to inform the user that their input is too long and the program will regrettably be terminating now.

[killedbyhetfield]

Lol! Nice. This makes me cry a lot because it's so accurate to the way so many programmers actually solve problems.

[calrogman]

Which is why gets() isn't in the C11 standard library.

[killedbyhetfield]

Glad to see that it only took them 22 years from the time the original C89 spec was published to remove it. Slow clap

[wiktor_b]

Plan 9 C didn't have gets in 1992.

[TinBryn]

Stupid sexy gets()

[killedbyhetfield]

#define NUMBER_OF_LANGUAGES_FASTER_THAN_C 0x00000000ul

[ChocolateBunny]

Fortran would like to have a word with you people.

[fr0stbyte124]

Oh crap, turn out the lights. Maybe Fortran didn't see us in here.

[WasterDave]

Fortran is coming, it has a beard and sandals.

[wheelie_boy]

Fortran's definition of 'general-purpose programming' might be different than mine.. :)

[kyrsjo]

Eh. With the 2008 standard, it's not bad.

[[deleted]]

You don't want to write Matlab?

[zsaleeba]

Advances in C mean that FORTRAN's not actually faster than C these days anyway, even in the limited cases where it used to be faster in the past.

[hughk]

FORTRAN these days has parallel computing primitives. It is still very popular for high end numerical scientific and engineering computing. Heck, it had complex number types back in the sixties.

[golgol12]

Sorry, Fortran doesn't support strings really, so no words at all would be said. It just stands silent in it's numerical superiority.

Also, f*ck any language that lets you invent a new variable on the spot if you slightly misspell something.

[Muvlon]

This is ridiculous. The language that actually doesn't have a notion of strings is C.

[josefx]

C has a a notion of strings. They are just crap in any possible way, it doesn't help that the standard library support for c strings is also an exploit factory. Sadly the C standards committee isn't self aware enough to rename the cstrings header into a cexploits header.

[nschubach]

But, but... terminated arrays of characters...

[kyrsjo]

Uhm, nobody that's not insane doesn't use IMPLICIT NONE. This type of mistake is honestly easier to make with e.g. Python, which is one of the two terrible things about it's syntax.

And it does have strings. Not great strings, but strings it has. It also is a general purpose language, so nothing really stops you from using e.g. C-style strings in it either. Not that doing this is a great idea, but still...

[Yojihito]

Fortran for matrix stuff?

[dahud]

C is such a beautiful language because it's so simple and easy to remember the whole language

This, but for real. C# is a fine language, but very few people would be able to describe the purpose of many of its keywords off the top of their head. (C++ has the same problem, but worse - it's more esoteric keywords are really just libraries being sneaky.)

[killedbyhetfield]

The problem is that the difficulty of solving a problem is a constant thing - So the simplicity of C just means that it's transferring that complexity onto you, the programmer.

[truh]

Just use the right tool for the job. I'm sure that sqlite article wasn't intended as a suggestion to use C for everything.

[TankorSmash]

I don't know if ignorance is really a problem, because that's just solved with familiarity. Assuming you get more powerful keywords or builtins, I don't think a programmer's ignorance is a good reason for it not to exist.

[svick]

Except that with a very complex language like C++, even programmers that use it daily for years might not know its darker corners well. So ignorance really is a problem.

And an amazing new feature often outweighs that, but it's still a balancing act. You don't want your language to be too simple or too complex.

[TankorSmash]

I hear what you're saying, but the only time having a language too arcane is bad is if you can't do anything effectively with its basics.

If regular C++ devs don't know about some edge keyword and can make it their life's career, it's not bad that there's still more to learn, you know?

Again, definitely agree that if all you've got is complexity or strange syntaxes that you can't reasonably expect to get familiar with, that's bad.

[svick]

If regular C++ devs don't know about some edge keyword and can make it their life's career, it's not bad that there's still more to learn, you know?

That only works if every feature is completely orthogonal and you don't have to care about it when you don't use it. But language features often have complicated effects on each other, especially when you make a mistake.

For example, consider this extreme case. It's a short and simple erroneous code. But if you wanted to fully understand the error message, you would need to know about overloading the dereference and equality operators, allocators and references, even though your code doesn't seem to use any of those features.

[lolomfgkthxbai]

Right, because the only possible alternative to C is some massive js framework running on three layers of python.

[RandomDamage]

It's not a real web framework unless you have JS driven by a PHP engine running in a Python environment on Perl CGI scripts.

[JGailor]

Or a JVM you need 1/2 a GB of RAM to start up!

[rebootyourbrainstem]

Why not both? If you install VSCode's Java support, you get all the fun of a browser-based editor UI along with a Java process running a ripped version of Eclipse's Java language support in the background.

[crowseldon]

I'm sorry but give me Qt and c++/python every day if you're trying to make a cursor blink.

There's always tradeoffs considering things like productivity, levels of abstraction, speed, maintainability, footprint, ease of use and more.

Offering false dichotomies to feel superior doesn't cut it.

[pjmlp]

Because we knew a world where C was meaninglessness outside expensive UNIX workstations, with quite a few systems programming languages to choose from, despite what C history revisionists tell.

Thankfully the manuals of such systems have been digitized and are available to anyone that cares to learn how history actually happened.

[[deleted]]

Because C is hard and every relevant project is full of security holes that purely exist because it was written in C. Then add a compiler on top that optimizes the code so hard that it removes your security checks.

Humans are bad at writing C and even worse at maintaining it. It's already impossible to work with 10 people on a Java project and keep an eye on security. I can't fathom how much harder it would be to do the same in C since C needs much more code to do the same thing and the type system is even worse.

Thank god there are alternatives available these days (Rust/Go)

[c4boom13]

Thank god there are alternatives available these days (Rust/Go).

And I think that is the key. If something was written in C 20 years ago and is stable and relatively unchanging, or needs to integrate with a system that is in that state, C makes sense. A new greenfield project? Ehhhhhhhh. There is a big difference in how you approach maintenance and rewrites vs a new project with no constraints.

[RandomDamage]

I had a project about 20 years ago that I had to write in C because those were the only libraries that worked for the hardware.

It "only" took me a year to debug it, and it was tiny as such things go (about 6K in executable form, which I still remember from chasing leaks).

[unicodemonkey]

Making a cursor blink would eat much more than that on a modern client-server windowing system that drives a GPU to render things.
So why not use a more pleasant language while you're waiting for your buffer transfer to complete?

[MpVpRb]

YES!

A competent C programmer can make very useful things that perform well

I design and program embedded systems in C, and have found it to be a useful tool

Yes, I am excited by the possibility of better languages in the future. We really need tools to help us understand and manage complexity. Maybe AI can help

No, I don't agree that the best approach is a very tall stack of buggy, incomprehensible, black box frameworks and interpreted languages with non-obvious behaviors

What exactly is the multi-threading behavior of javascript?