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

331–340 of 411 posts

Re: Why Is SQLite Coded In C

#331

Post by WesolyKubeczek »

devjab wrote: post #241
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…

Have you tried writing Python extension modules in Zig instead of C? How is it?

Re: Why Is SQLite Coded In C

#332

Post by scuff3d »

steveklabnik wrote: post #327
scuff3d wrote: post #191

Earlier quoted context omitted.

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

> Literally any language that does the same will be the same speed but not faster, because there's no way to be faster. It's physically impossible. There is nothing special about C that makes this true. C has semantics, just like any language, that are higher level than assembly, and sometimes, those semantics make the code slower than other languages that have different semantics. Consider this C function: void redu…

Leave it to hackernews to be overly pedantic.

Yes, obviously different languages will produce different assembly based on the language semantics. So you will get performance differences. And it's certainly possible for code written in Rust or Zig or Odin to be more performant then C code depending on how it's written.

My point was about classes of languages (for lack of a better term). Loosely, from fastest to slowest you have:

1. Compiled languages (meaning straight to machine code) with manual memory management

2. Compiled languages with garbage collection

3. Languages that run in VMs but are AOT compiled or JITed

4. Purely interpreted languages.

I acknowledge that not all languages fit nicely into these and there will be exceptions, but it's a convenient mental model that's close enough for these purposes.

Languages in the first category are going to be the most performant. Obviously there will be some variation between them based on how the code is written, but unless it's written really poorly it's not going to drop into an entirely different category. Where as languages in other categories are going to be far more difficult if not impossible to get close to the same kind of performance.

And there is no meaningfully huge jumps left after the first group. We are all the way down at optimizing assembly code, and that's where you start to hit physical limitations. Some number of operations have to be executed and the CPU can only execute them so fast.

Re: Why Is SQLite Coded In C

#333

Post by devjab »

WesolyKubeczek wrote: post #331
devjab wrote: post #241

Earlier quoted context omitted.

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…

Have you tried writing Python extension modules in Zig instead of C? How is it?

No, just C ABI compatible libraries. Maybe when there are two fridays in a week we will have enough time to do some actual adoption.

Re: Why Is SQLite Coded In C

#334

Post by steveklabnik »

scuff3d wrote: post #332
steveklabnik wrote: post #327

Earlier quoted context omitted.

> Literally any language that does the same will be the same speed but not faster, because there's no way to be faster. It's physically impossible. There is nothing special about C that makes this true. C has semantics, just like any language, that are higher level than assembly, and sometimes, those semantics make the code slower than other languages that have different semantics. Consider this C function: void redu…

Leave it to hackernews to be overly pedantic. Yes, obviously different languages will produce different assembly based on the language semantics. So you will get performance differences. And it's certainly possible for code written in Rust or Zig or Odin to be more performant then C code depending on how it's written. My point was about classes of languages (for lack of a better term). Loosely, from fastest to slowes…

I agree with you that there are broad, loose categories. The only thing I object to is splitting C out from category 1 and putting it into some kind of category 0.

Re: Why Is SQLite Coded In C

#335

Post by okanat »

binary132 wrote: post #70
selcuka wrote: post #67

Earlier quoted context omitted.

Ok, but you can still test all the branches in your source code and have 100% coverage. Those additional `if` branches are added by the compiler. You are responsible for testing the code you write, not the one that actually runs. Your compiler's test suite is responsible for the rest. By the same logic one could also claim that tail recursion optimisation, or loop unrolling are also dangerous because they change the…

If they produce control flow _in the executable binary_ that is untested, then they could conceivably lead to broken states. I don’t believe most of those sorts of transformations cause alternative control flows to be added to the executable binary. I don’t think anyone would find the idea compelling that “you are only responsible for the code you write, not the code that actually runs” if the code that actually runs…

Well this way of arguing it may seem smart but it is not fully correct.

Google already ships binaries compiled with Rust in Android. They are actually system services which are more critical than SQLite storage of apps.

Moreover Rust version of SQLite can ship binaries compiled with a qualified compiler like Ferrocene: https://ferrocene.dev/en/ (which is the downstream, qualified version of standard Rust compiler rustc). In qualification process the compiler is actually checked whether it generates reasonable machine code against a strict set of functional requirements.

Most people don't compile SQLite with qualified versions of GCC either. So this exact argument actually can be turned against them.

Re: Why Is SQLite Coded In C

#336

Post by devjab »

Hendrikto wrote: post #260
devjab wrote: post #241

Earlier quoted context omitted.

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…

> We attempted to move into Go […], but similar to interpreted languages it can be rather hard to optimize it. […] So it was easier to just go with Python I don’t get that. You had trouble optimizing Go, so you went with Python?

We had Python and C. We aimed for Go. Now we have Python and C. Yhe deeper story is more change management than technically. We hoped we could obtain advantages from Go because we, perhaps naively, figured it would lessen the gap between programming and software engeniering. We have a lot of people who can build software, but few who can optimise it. We hoped Go would give us a lot of "free" optimisaton, but it didn't. It also wasn't as easy to transition not SWE's into not Python as we had hoped. We made no major rewrites, we instead build some of our new tools and services in Go. Some of these have been phased out, others will live out their lifecycles as is.

I personally really like Go, but I feel like I now have a better understanding of why so many teams stick with c/c++ without even considering adopting Go, Rust or similar.

Re: Why Is SQLite Coded In C

#337

Post by scuff3d »

steveklabnik wrote: post #334
scuff3d wrote: post #332

Earlier quoted context omitted.

Leave it to hackernews to be overly pedantic. Yes, obviously different languages will produce different assembly based on the language semantics. So you will get performance differences. And it's certainly possible for code written in Rust or Zig or Odin to be more performant then C code depending on how it's written. My point was about classes of languages (for lack of a better term). Loosely, from fastest to slowes…

I agree with you that there are broad, loose categories. The only thing I object to is splitting C out from category 1 and putting it into some kind of category 0.

I'm not? I'm literally saying C, Rust, Zig, Odin, and any other manually memory managed language that compiles straight to machine code is the fastest category you can have, because at that point your bumping against literal hardware limitations. There is no category below them in terms of performance.

"None faster" means you can't just change languages like you could from Java to C (assuming you can write quality code in both) and see a substantial performance boost.

Re: Why Is SQLite Coded In C

#338

Post by steveklabnik »

scuff3d wrote: post #337
steveklabnik wrote: post #334

Earlier quoted context omitted.

I agree with you that there are broad, loose categories. The only thing I object to is splitting C out from category 1 and putting it into some kind of category 0.

I'm not? I'm literally saying C, Rust, Zig, Odin, and any other manually memory managed language that compiles straight to machine code is the fastest category you can have, because at that point your bumping against literal hardware limitations. There is no category below them in terms of performance. "None faster" means you can't just change languages like you could from Java to C (assuming you can write quality co…

> Of course nothing is going to be faster then C, ... because there's no way to be faster. It's physically impossible.

This reads to me as if you're saying C is in a class of its own. That may not be what you meant! But it's what I understood. C is the fastest language, period, and others may approach its speed (which is the ... part) but cannot surpass it. This is different than something like "C, Rust, Zig, and Odin are roughly the fastest languages."

Anyway, it's all good, we understand each other now. Sorry for appearing overly pedantic.

Re: Why Is SQLite Coded In C

#339

Post by slashdev »

frumplestlatz wrote: post #215
slashdev wrote: post #109

Earlier quoted context omitted.

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

The founders came from ScyllaDb, I wouldn't be so quick to count them out. The repo has a lot of contributors and traction. As long as the company survives, I think it has a bright future.
Post reply on HN