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

341–350 of 411 posts

Re: Why Is SQLite Coded In C

#341

Post by rileymat2 »

simonask wrote: post #223
john_the_writer wrote: post #220

Earlier quoted context omitted.

Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.

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.

Re: Why Is SQLite Coded In C

#342

Post by rileymat2 »

jen20 wrote: post #283
john_the_writer wrote: post #220

Earlier quoted context omitted.

Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.

A memory leak is not a memory safety issue.

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

Re: Why Is SQLite Coded In C

#343

Post by thfuran »

selcuka wrote: post #67
lionkor wrote: post #50

Earlier quoted context omitted.

It's not like that, the compiler explicitly doesn't do compile-time checks here and offloads those to the runtime. Rust does not stop you from writing code that accesses out of bounds, at all. It just makes sure that there's an if that checks.

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…

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

Re: Why Is SQLite Coded In C

#344

Post by zenxyzzy »

I'm really getting tired of resume driven development. Choosing technology X because the coder wants it on their resume is a truly shitty reason. Rust is just the lastest trendy bullshit that will make meh programmers into superstars.

Re: Why Is SQLite Coded In C

#345

Post by pjmlp »

wat10000 wrote: post #300
pjmlp wrote: post #290

Earlier quoted context omitted.

Sure if the only thing that matters is what happened in 1990, and nothing else that came afterwards. Also if we ignore the historical tellings from Apple employees at the time, in places like the Folklore book and CHM interviews.

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

> The key Apple player behind Object Pascal was Larry Tesler who recruited the help of Niklaus Wirth, the creator of Pascal, to clean up the syntax of Clascal. Object Pascal was used to develop the extensive MacApp class library. This library was fully documented by Apple via several books and the source code for MacApp was provided to developers.

https://www.folklore.org/3rd_Party_Developers_and_Macintosh_...

> Macintosh development in the early days (circa 1983-1985) was done using the Apple Lisa computer and its Lisa Workshop development environment. I originally used a Lisa 2/5 model which contained 1M byte of RAM, an internal 400K 3.5" Sony floppy drive, and an external 5M byte ProFile hard drive (yes, 5M as in mega bytes was considered a rather large drive in those days). I later used a Lisa 2/10 model which had an additional 10M byte internal Widget hard drive which gave me a total of 15M bytes of hard drive storage.

> The Lisa Pascal language was very powerful and compiled Pascal source files to Motorola 68000 object code files. I never found a need to use the Workshop's 68000 assembler since everything I needed for my application could be written in the higher level Lisa Pascal language. Macintosh application resource information was created as text files which were then compiled to a binary format using the RMaker resource compiler. Transferring a Macintosh object program from the Lisa to the Macintosh required the Lisa utility program MacCom which copied Lisa files to a Macintosh formatted disk in the Lisa's 400K internal disk drive. MacCom combined separate Lisa data and resource fork files which were stored on the Lisa's hard drive and stored them as single documents on the Macintosh floppy.

> Macintosh programming was based on a collection of programming libraries called "units" in Pascal parlance. These resided on the Lisa and implemented the Macintosh application programming interface (API) called the Toolbox and Operating System by Apple. These libraries came on Lisa formatted disks called the Lisa Macintosh Supplement. I recall receiving around 3 or 4 supplements each with around a half dozen disks with these libraries. These disks also contained Macintosh utility and sample applications such as the Uriah Heap desk accessory by Andy Hertzfeld (called desk ornaments in the early days), the Edit text editor, and the File application by Cary Clark which showed detailed examples of Macintosh programming.

Re: Why Is SQLite Coded In C

#346

Post by 0xffff2 »

weinzierl wrote: post #216
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…

"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/

The fact that there are "cloud pricing" and "schedule a call" links already tells me all I need to know. Doesn't seem like this is a product that is really competing with SQLite at all.

Re: Why Is SQLite Coded In C

#347

Post by selcuka »

thfuran wrote: post #343
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…

>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 gcc, not vendor them in your own repo.

Re: Why Is SQLite Coded In C

#348

Post by frumplestlatz »

slashdev wrote: post #339
frumplestlatz wrote: post #215

Earlier quoted context omitted.

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.

So they have a history of using the legitimacy, trust, and infrastructure of the open-source ecosystem to grow adoption and contributions, then gradually shifting constraints in favor of monetization and control?

Either way, the math is different this time. SQLite isn’t heavy server-side software written in Java with weaknesses that leave it obviously open for market disruption.

It’s also a public domain gift to the world that literally everything has deployed — often in extremely demanding and complex environments.

I work for a major consumer product manufacturer, and I can guarantee that we will not be switching away from SQLite anytime soon, and if we ever do, it will not be to a VC-backed project with a history like this one has, no matter how much hype startup bros try to create around the idea of disrespectful and appropriative disruption.

VC-funded ‘open’ databases almost always follow the same arc: borrow legitimacy, capture attention, then fence it off. It’s the inevitability of the incentives they’ve chosen.

Re: Why Is SQLite Coded In C

#349

Post by scuff3d »

steveklabnik wrote: post #338
scuff3d wrote: post #337

Earlier quoted context omitted.

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

Fair. I was using C as short hand for that entire class of languages. I could have been clearer.

Re: Why Is SQLite Coded In C

#350

Post by nimih »

timv wrote: post #169
nimih wrote: post #147

Earlier quoted context omitted.

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

The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one. The choices therefore are: 1. No bound check 2. Bounds check inserted, but that branch isn't covered by tests 3. Bounds check inserted, and that branch is covered by tests I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) Because if it is indeed an impossibl…

> Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter.

At the point where a load-bearing piece of your quality assurance strategy is 100% branch coverage of the generated machine code, it very much does matter.

> I'm skeptical of the claim that if (3) is infeasible then the next best option is (1)

In the general case, obviously not. But, in the specific case we’re discussing, which is that (2) has the rider of “the development team will be forced to abandon a heretofore important facet of their testing strategy at the exact moment they are rewriting the entire codebase in a language they are guaranteed to have less expertise in,” I think (1) seems pretty defensible.

Post reply on HN