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

141–150 of 411 posts

Re: Why Is SQLite Coded In C

#141

Post by metaltyphoon »

dangus wrote: post #131
Deanoumean wrote: post #125

Earlier quoted context omitted.

The argument you propose only works for justifying a maintenance mode for and old codebase. If you want to take the chance to turn away new developers from complex abominations like C++ and Rust and garbage collected sloths like Java and get them to consider a comparatively simple but ubiquitous language that is C, you have to offer more.

Is SQLite looking for new developers? Will they ever need a large amount of developers like a mega-corp that needs to hire 100 React engineers?

No, but as morbid as this sounds, the three(?) devs one day will pass away so now what?

Re: Why Is SQLite Coded In C

#142

Post by steveklabnik »

gerdesj wrote: post #127
steveklabnik wrote: post #107

Earlier quoted context omitted.

Rust has long worked with distro package maintainers, and as far as I know, Rust is packaged in every major Linux distribution. There are other worlds out there than Linux.

So why insist on rustup?

Distributions generally package the versions of compilers that are needed to build the programs in their package manager. However, many developers want more control than that. They may want to use different versions of the compiler on different projects, or a different version than what’s packaged.

Basically, people use it because they prefer it.

Re: Why Is SQLite Coded In C

#143

Post by [deleted] »

csande17 wrote: post #130
steveklabnik wrote: post #123

Earlier quoted context omitted.

Every compiler has soundness bugs. They’re just programs like any other. This isn’t exclusive to Rust.

In general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...

[deleted]

Re: Why Is SQLite Coded In C

#144

Post by steveklabnik »

csande17 wrote: post #130
steveklabnik wrote: post #123

Earlier quoted context omitted.

Every compiler has soundness bugs. They’re just programs like any other. This isn’t exclusive to Rust.

In general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...

What makes you say this is a core part of the marketing strategy? I don’t think Rust’s marketing has ever focused on compiler bugs or their absence.

Re: Why Is SQLite Coded In C

#145

Post by aw1621107 »

QuiEgo wrote: post #112
steveklabnik wrote: post #27

Earlier quoted context omitted.

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. I’d love to see rust be so stable that MSRV is an anachronism. 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.

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

Re: Why Is SQLite Coded In C

#146

Post by dathinab »

gerdesj wrote: post #127
steveklabnik wrote: post #107

Earlier quoted context omitted.

Rust has long worked with distro package maintainers, and as far as I know, Rust is packaged in every major Linux distribution. There are other worlds out there than Linux.

So why insist on rustup?

different goals

the rust version packaged in distros is for compiling rust code shipped as part of the distro. This means it

- is normally not the newest version (which , to be clear, is not bad per see, but not necessary what you need)

- might not have all optional components (e.g. no clippy)

but if you idk. write a server deployed by you company

- you likely want all components

- you don't need to care what version the distro pinned

- you have little reason not to use the latest rust compiler

for other use cases you have other reasons, some need nightly rust, some want to test against beta releases, some want to be able to test against different rust versions etc. etc.

rustup exist (today) for the same reason why a lot of dev projects use project specific copies of all kinds of tooling and libraries which do not match whatever their distro ships: The distro use-case and generic dev-use case have diverging requirements! (Other examples nvm(node), flutter, java etc.).

Also some distros are notorious for shipping outdated software (debian "stable").

And not everything is Linux, rustup works on OSX.

Re: Why Is SQLite Coded In C

#147

Post by nimih »

Aurornis wrote: post #62
bfkwlfkjf wrote: post #16

> 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. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

I guess I don’t find that argument very compelling. If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested. This feels like chasing arbitrary 100% test coverage at the expense of safety. The code quality isn’t actually improved by omitting the checks even though it makes testing coverage go up.

> If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested.

I don't think I would (personally) ever be comfortable asserting that a code branch in the machine instructions emitted by a compiler can't ever be taken, no matter what, with 100% confidence, during a large fraction of situations in realistic application or library development, as to do so would require a type system powerful enough to express such an invariant, and in that case, surely the compiler would not emit the branch code in the first place.

One exception might be the presence of some external formal verification scheme which certifies that the branch code can't ever be executed, which is presumably what the article authors are gesturing towards in item D on their list of preconditions.

Re: Why Is SQLite Coded In C

#148

Post by Ferret7446 »

cogman10 wrote: post #88
anitil wrote: post #38

Earlier quoted context omitted.

It's the sort of argument that I wouldn't accept from most people and most projects, but from Dr Hipp isn't most people and Sqlite isn't most projects.

It's a bad argument. Certainly don't get me wrong, SQLite is one of the best and most thoroughly tested libraries out there. But this was an argument to have 4 arguments. That's because 2 of the arguments break down as "Those languages didn't exist when we first wrote SQLite and we aren't going to rewrite the whole library just because a new language came around." Any language, including C, will emit or not emit inst…

> Any language, including C, will emit or not emit instructions that are "invisible" to the author

Presumably this is why they do 100% test coverage. All of those instructions would be tested and not invisible to the test suite

Re: Why Is SQLite Coded In C

#149

Post by Ferret7446 »

hypeatei wrote: post #83
oconnor663 wrote: post #64

Earlier quoted context omitted.

Yes. You have to write `unsafe { ... }` around it, so there's an ergonomic penalty plus a more nebulous "sense that you're doing something dangerous that might get some skeptical looks in code review" penalty, but the resulting assembly will be the same as indexing in C.

I figured, but I guess I don't understand this argument then. SQLite as a project already spends a lot of time on quality so doing some `unsafe` blocks with a `// SAFETY:` comment doesn't seem unreasonable if they want to avoid the compiler inserting a panic branch for bounds checks.

If you put unsafe around almost all of your code (array indexing) aren't you better off just writing C?

Re: Why Is SQLite Coded In C

#150

Post by dathinab »

wrs wrote: post #84
steveklabnik wrote: post #27

Earlier quoted context omitted.

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

For a little more color on 5, as a user of no_std Rust on embedded processors I use crates like heapless or trybox that provide Vec, String, etc. APIs like the std ones, but fallible. Of course, two libraries that choose different no_std collection types can't communicate...but hey, we're comparing to C here.

even OOM isn't that different

like there are some things you can well in C

and this things you can do in rust too, through with a bit of pain and limitations to how you write rust

and then there is the rest which looks "hard but doable" in C, but the more you learn about it the more it's a "uh wtf. nightmare" case where "let's kill+restart and have robustness even in presence of the process/error kernel dying" is nearly always the right answer.

Post reply on HN