Live data from Hacker News

Why Is SQLite Coded In C

sqlite.org

351–360 of 411 posts

Re: Why Is SQLite Coded In C

#351

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

"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." We will see. On the Rust side there is Turso which is pretty active. https://turso.tech/

But Turso is a for profit company that's bound to rug pull eventually.

So SQLite is still the bar

Re: Why Is SQLite Coded In C

#352
post #34

Earlier quoted context omitted.

So is the argument that safe langs produce stuff like: // pseudocode if (i >= array_length) panic("index out of bounds") that are never actually run if the code is correct? But (if I understand correctly) these are checks implicitly added by the compiler. So the objection amounts to questioning the correctness of this auto-generated code, and is predicated upon mistrusting the correctness of the compiler? But presuma…

Bound checks are usually conditionally compiled. That's more a kind of "contract" you'll verify during testing. In the end the software actually used will not check anything. #ifdef CONTRACTS if (i >= array_length) panic("index out of bounds") #endif

an hygienic way to handle that is often "assert", can be a macro or a built in statement.The main problem with assertions is the side-effects. The verification must be pure...

Re: Why Is SQLite Coded In C

#353

Earlier quoted context omitted.

This is a bit of a misunderstanding. Safe code is just code that cannot have Undefined Behavior. C and C++ have the concept of "soundness" just like Rust, just no way to statically guard against it.

There is more than undefined behavior, if I was to define using an uninitialized variable as yielding whatever data was previously in that location, it is well defined but unsafe.

That could be well defined for POD types like arrays of bytes (I think in that case they call it "freezing"), but you'd still have undefined behavior if the type in question contained pointers. Also at least in Rust it's UB to create illegal values of certain types, like a bool that's anything other than 0 or 1.

Which is all kind of to say, all of Rust's different safety rules end up being surprisingly densely interconnected. It's really hard to guarantee one of them (say "no use-after-free") without ultimately requiring all of them ("no uninitialized variables", "no mutable aliasing", etc).

Re: Why Is SQLite Coded In C

#354

Earlier quoted context omitted.

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…

There's no such thing as "Rust evangelists targeting existing projects" as some sort of broad strategy. What you're observing is that some people like to write programs in Rust, and so they choose to write new code in Rust. For some people, writing versions of software they understand already is a good way to learn a language, for some, it's that they don't like some aspect of the existing software and want to make s…

> That is, nobody perceives, say, "the silver searcher" as being some sort of nefarious plot to re-write grep, but they did with ripgrep, even though that's not what it is trying to do.

I have a suspicion as to why this perception exists in the C++ crowd.

I don't think it's because of evangelists. C++ was that evangelized language in the early 90's, but after a period in the sun it then survived the evangelism of Java, Python, Go, and others, despite losing ground to them in general purpose tasks.

And that's because all of those other languages, while being much safer than C++, came at the cost of performance or the overhead of a runtime. There was really no other language that had the expressiveness of C++ while allowing the developer to get down to the bare metal if they needed speed.

The existence and growing popularity of Rust changes that calculus, and I imagine that makes certain developers who might have a lot of investment in the C++ ecosystem defensive, causing them to overreact to any perceived slight in a way that other languages simply don't provoke.

Re: Why Is SQLite Coded In C

#355

Earlier quoted context omitted.

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…

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

Re: Why Is SQLite Coded In C

#356

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.

And when they do that, they'll be vilified for "rewriting in Rust" and creating nothing new.

Who actually is nagging people multiple times per day to do free labor for them and rewrite a project in a completely different programming language?

Re: Why Is SQLite Coded In C

#357
post #345

Earlier quoted context omitted.

What is with people on HN using a specific example and then getting annoyed when I respond to it? You specifically said Apple launched the original Mac without C. Which is true, but the implication that it used Pascal is not. I'm not addressing what happened years later. Can you elaborate on these historical tellings? From what I found on folklore.org, Lisa OS had a bunch of Pascal, and the Mac system borrowed a bunc…

http://pascal.hansotten.com/ucsd-p-system/apple-pascal/ > When Apple began development of the Macintosh (1982) Apple used Lisa Pascal and the Lisa Workshop for system software development. > Object Pascal for the Macintosh was developed by Apple starting in 1985 to support more rapid and more standardized development of Macintosh programs. Available for only MPW, Object Pascal is a descendant of the Lisa Clascal comp…

Folklore.org has many stories about writing Lisa OS code in Pascal, about rewriting various pieces in assembly for the Macintosh, and developing apps in Pascal, but I can’t find any mention of actually writing any part of the original Mac system in Pascal.

Nothing you’ve quoted says otherwise. The closest is the very first sentence, but all it says is that Pascal was in use at Apple when the Macintosh project began, not that it was used for that project.

Re: Why Is SQLite Coded In C

#358

Earlier quoted context omitted.

>You are responsible for testing the code you write, not the one that actually runs That's a bizarre claim. The source code isn't the product, and the product is what has to work. If a compiler or OS bug causes your product to function incorrectly, it's still your problem. The solution is to either work around the bug or get the bug fixed, not just say "I didn't write the bug, so deal with it."

You are a better developer than me, then. I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". If you are suspicious about gcc, you should submit your patches to…

>I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate?

Are you asking whether I write integration tests? Yes, I do. And at work there's a whole lot of acceptance testing too.

>There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc".

They're not proposing writing unit tests for gcc, only actually testing what gcc produces from their source. You know, by executing it like tests tend to do. Testing only the first party source would mean relying entirely on static source code analysis instead.

Re: Why Is SQLite Coded In C

#359

Earlier quoted context omitted.

You are a better developer than me, then. I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". If you are suspicious about gcc, you should submit your patches to…

>I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? Are you asking whether I write integration tests? Yes, I do. And at work there's a whole lot of acceptance testing too. >There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit te…

> Are you asking whether I write integration tests? Yes, I do.

Exactly. You don't need unit tests for the binary output. You want to test whether the executable behaves as expected. Therefore "rust adds extra conditional branches that are never entered, and we can't test those branches" argument is not valid.

Re: Why Is SQLite Coded In C

#360
post #345

Earlier quoted context omitted.

http://pascal.hansotten.com/ucsd-p-system/apple-pascal/ > When Apple began development of the Macintosh (1982) Apple used Lisa Pascal and the Lisa Workshop for system software development. > Object Pascal for the Macintosh was developed by Apple starting in 1985 to support more rapid and more standardized development of Macintosh programs. Available for only MPW, Object Pascal is a descendant of the Lisa Clascal comp…

Folklore.org has many stories about writing Lisa OS code in Pascal, about rewriting various pieces in assembly for the Macintosh, and developing apps in Pascal, but I can’t find any mention of actually writing any part of the original Mac system in Pascal. Nothing you’ve quoted says otherwise. The closest is the very first sentence, but all it says is that Pascal was in use at Apple when the Macintosh project began,…

Whatever makes you happy to keep your view on the matter.

https://bitsavers.org/pdf/apple/mac/Inside_Macintosh_Vol_1_1...

Post reply on HN