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

401–410 of 411 posts

Re: Why Is SQLite Coded In C

#401

Post by yrashk »

blibble wrote: post #255
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…

> The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use. try marketing your burger company as "The Next Evolution of McDonalds" and see what happens

This happened to FerretDB

Re: Why Is SQLite Coded In C

#402

Post by aw1621107 »

QuiEgo wrote: post #396
aw1621107 wrote: post #145

Earlier quoted context omitted.

> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?

This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in. For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space. Toolchain updates invalidate you…

I feel like that's ever-so-slightly different from what GP was talking about. Beyond the potential hyperbole ("unthinkable", "any reason"), I think there's a difference between "we support C89 because nothing in later standards is useful/interests us" (which is what I interpreted GP to be talking about) and "we support C89 because we want to support platforms/compilers that don't support C99/later". cjson looks like an example of the latter, at least:

> cJSON is written in ANSI C (C89) in order to support as many platforms and compilers as possible.

And if you look through the issues/PRs you can see there was at least nominal interest in moving to later standards, though it seems those plans never came to fruition.

Not entirely sure about FreeRTOS, but something similar wouldn't surprise me all that much.

Re: Why Is SQLite Coded In C

#403

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #318
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…

This begs the question of why Rust evangelists keep targeting existing projects instead of focusing writing new, better software. In theory these languages should allow software developers to write programs that they would not, or could not, attempt using languages without automatic memory management Instead what I see _mostly_ is re-writes and proposed re-writes of existing software, often software that has no netwo…

"The Silver Searcher" is a program written in the _same_ "unsafe" language as grep

This is obviously not analogous to Rust evangelism that targets projects written in C

The author claims the program is a clone of ack; ack is written in a "safe" language

https://geoff.greer.fm/ag/

https://beyondgrep.com/

Re: Why Is SQLite Coded In C

#404

Post by vrighter »

rileymat2 wrote: post #342
jen20 wrote: post #283

Earlier quoted context omitted.

A memory leak is not a memory safety issue.

No, but it can be dangerous when you run out of memory for critical systems.

yes, but that is neither here nor there. You can create a memory leak perfectly cromulently in rust too

Re: Why Is SQLite Coded In C

#405

Post by ulfgard »

jemmyw wrote: post #372
btilly wrote: post #181

Earlier quoted context omitted.

What the best strategy is depends on your use case. The use case that SQLite has chosen to optimize for is critical embedded software. As described in https://www.sqlite.org/qmplan.html , the standard that they base their efforts on is a certification for use in aircraft. If mission critical software on a plane is allowed to crash, this can render the controls inoperable. Which is likely to lead to a very literal cra…

You're right and when I thought about it more I considered that "supervisor" isn't what I would want. Rather I'm thinking raising errors to the program that embeds sqlite so that it can decide what to do. I do have a desktop app that uses sqlite and I'd rather it raised an error than tried to recover.

But getting back into a well-defined state which you can communicate via an error is a viable recovery strategy.

This state can be "the database is corrupt", allowing for a restore from backup, it can also be "shut down gracefully" and communicate that.

Especially for databases there is a ton to concinder: what about database entries that are not committed yet? When you run into oom, should you at least try to commit the data still in ram by freeing as much space as possible?

Re: Why Is SQLite Coded In C

#406

Post by uecker »

dathinab wrote: post #329
uecker wrote: post #314

Earlier quoted context omitted.

The point is that matrix transpose should be trivial. But my main point really is that looking at CVEs is just nonsense. In both cases it is is a rather meaningless.

except that if you read into the actual issue you will realize that transposing matrices high performant is surprisingly not trivial, e.g. see this code code: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... furthermore the issue at core was an integer overflow, which is tricky in all languages and e.g. has poppet up on HN recently in context of "proven correct" code still having bugs (because the prov…

Bounds checking for matrices is trivial. The point is that once you compete with C and need to do something slightly more complex, mistakes also can happen in Rust. Now, we can have a discussion if it is still safer and I may even agree), but it defeats the "eliminate a whole class of issues" marketing, doesn't it?

Re: Why Is SQLite Coded In C

#407

Post by QuiEgo »

aw1621107 wrote: post #402
QuiEgo wrote: post #396

Earlier quoted context omitted.

This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in. For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space. Toolchain updates invalidate you…

I feel like that's ever-so-slightly different from what GP was talking about. Beyond the potential hyperbole ("unthinkable", "any reason"), I think there's a difference between "we support C89 because nothing in later standards is useful/interests us" (which is what I interpreted GP to be talking about) and "we support C89 because we want to support platforms/compilers that don't support C99/later". cjson looks like…

Sure, I think we’re essentially looking at the same thing from different angles. They are saying the changes in the C standard are minor enough that forcing people to upgrade isn’t worth the costs, such as losing compatibility with old toolchains for niche platforms. So they stay on an old C version.

It would be amazing if Rust was as the point where people were ready to have conversations like that.

New versions of Rust add so many handy, useful features the cost of staying on old Rust versions is very high right now. Or put differently, the ROI of picking up new versions of Rust is very very VERY good. So most packages do.

Going back to the bigger picture issue though: it’s very common in embedded to lock your toolchain and very rarely change it. This is very desirable to drive down risk and testing burden. It would be sweet if this was more easy to do in Rust. If I need to take an update to a dependency to pick up a bug fix, as it stands today, there’s a good chance these days that I’m going to hit something in the chain that bumped MSRV and will force me to update.

In real-world embedded projects using Rust, you end up with painful options: - chase MSRV of deps and keep on new Rust. Adds risk and testing burden. - minimize deps and reimplement everything yourself. Adds lots of cost. - use C and incur all of the memory safety risks, and assorted foot guns

In the end, Rust still feels worth it, but it’d be super nice to not have to make that trade.

Re: Why Is SQLite Coded In C

#408

Post by rstuart4133 »

steveklabnik wrote: post #11
rstuart4133 wrote: post #9

Earlier quoted context omitted.

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

A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors. Your example does what [] does already, it’s just a more verbose way of writing the same thing. It’s not the same behavior as sqlite.

> A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors.

Array access was just an example. My point was that Rust makes 100% code coverage for unit tests well neigh impossible.

For those of us who like 100% test coverage, that is a major annoyance. For way I use Rust that could be fixed by the tooling simply not counting unreachable!() lines as unreached. For Sqlite, who does branch coverage testing on the compiled binary you would have to go a step further, and provide a compile time option that elides all paths that lead to unreachable!() from the binary. I recall Sqlite saying when they changed to 100% branch coverage, their bug reports dropped by a factor of 7. I hope I remember that correctly. If I do, I'm pretty sure they won't be looking at Rust until they can achieve the same outcome. They can't come close now.

Replacing every array access with get_unchecked() and the consequent explosion of unsafe area's wouldn't fly with anyone I worked with. You did say to me in another thread unsafe is perfectly fine in Rust programs, but you are literally the only person holding that opinion I come across.

Re: Why Is SQLite Coded In C

#409

Post by peter_d_sherman »

>"1.3. Low-Dependency

Libraries written in C do not have a huge run-time dependency.

In its minimum configuration, SQLite requires only the following routines from the standard C library:

memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()

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. But even then, the number of dependencies is very small. Other "modern" languages, in contrast, often require multi-megabyte runtimes loaded with thousands and thousands of interfaces."

Very laudable!

(I should also point out that SQLite could conceivably be compiled with small (in terms of lines of code) C compilers like Fabrice Bellard's Tiny C Compiler (TCC). Also SQLite's few required standard C library routines listed above could conceivably be coded inside of SQLite itself(!) (they are, after all, just additional lines of C code in a different place -- and those could conceivably be moved or copied) -- thus removing the dependency/requirement for any standard C library whatsoever!)

Anyway, we love SQLite!

Re: Why Is SQLite Coded In C

#410

Post by MangoToupe »

itopaloglu83 wrote: post #355
MangoToupe wrote: post #321

Earlier quoted context omitted.

> This begs the question of why Rust evangelists keep targeting existing projects instead of focusing writing new, better software. Designing new software is orders of magnitude more difficult than iterating on existing software

Yes, of course, but if a project owner wants to stay with a non-rust programming language, maybe we should just let them be, instead of nagging them multiple times a day about why they haven't switched, in that case writing your own project with rust to prove that it can be done better is the way to go.

Hey if it increases participation, why not? I certainly don't blame anyone for avoiding the adhoc mess that is C
Post reply on HN