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

381–390 of 411 posts

Re: Why Is SQLite Coded In C

#381

Post by aw1621107 »

pklausler wrote: post #374
aw1621107 wrote: post #364

Earlier quoted context omitted.

Glad to hear it! Didn't turn up anything obvious in my brief search, but I was expecting some work towards newer standards at least.

Why would you expect that? There are few incentives to work on features that nobody is using.

Because given the work needed to actually get a feature into the standard I'd assume there's at least some demand motivating the addition.

I'd also be a bit hesitant about claiming that nobody is using said features. It's quite possible that the "new" feature is actually "just" a standardization of something that exists in practice. WG14 is hardly a stranger to that kind of thing, from what I understand; it wouldn't surprise me if something similar occurs for the Fortran/COBOL working groups as well.

Re: Why Is SQLite Coded In C

#382

Post by pklausler »

aw1621107 wrote: post #381
pklausler wrote: post #374

Earlier quoted context omitted.

Why would you expect that? There are few incentives to work on features that nobody is using.

Because given the work needed to actually get a feature into the standard I'd assume there's at least some demand motivating the addition. I'd also be a bit hesitant about claiming that nobody is using said features. It's quite possible that the "new" feature is actually "just" a standardization of something that exists in practice. WG14 is hardly a stranger to that kind of thing, from what I understand; it wouldn't…

That's a reasonable assumption, but it turns out to rarely be the case with WG5/SC22/J3. There are exceptions (like SIND, SINPI, &c.), but most new features in Fortran standards are committee inventions without prototypes, reference implementations, or official conformance test suites. This leads to incompatible implementations, and then lack of use in codes that need to be portable. It's a mess, really. I have a test suite of examples of this kind of thing that accumulated during the implementation of flang-new, in which it was a difficult task to figure out what portable Fortran really means in a way that's meaningful to users.

Re: Why Is SQLite Coded In C

#383

Post by aw1621107 »

pklausler wrote: post #382
aw1621107 wrote: post #381

Earlier quoted context omitted.

Because given the work needed to actually get a feature into the standard I'd assume there's at least some demand motivating the addition. I'd also be a bit hesitant about claiming that nobody is using said features. It's quite possible that the "new" feature is actually "just" a standardization of something that exists in practice. WG14 is hardly a stranger to that kind of thing, from what I understand; it wouldn't…

That's a reasonable assumption, but it turns out to rarely be the case with WG5/SC22/J3. There are exceptions (like SIND, SINPI, &c.), but most new features in Fortran standards are committee inventions without prototypes, reference implementations, or official conformance test suites. This leads to incompatible implementations, and then lack of use in codes that need to be portable. It's a mess, really. I have a tes…

I'll defer to your expertise here. If C++'s experience with similar situations is any indication it really does not seem like a fun spot to be in.

Does make me curious how the dynamics of the Fortran/COBOL committees differs from that of the C/C++ committees.

Re: Why Is SQLite Coded In C

#384

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…

https://sqlite.org/copyright.html

Public domain. No "copyleft" license needed

Being written in a small, fast, "old and boring" language may be part of what makes SQLite apealing. Another (related) part may be the thoughtfulness and carefulness of its author, e.g., "time, attention and testing"

The former, i.e., the author's "time, attention and testing", may matter more than the later, i.e., the author's language choice

As suggested by the top comment, in effect the author's language choice, by itself, may not matter with respect to the issue of "safety". If true, then even an "unsafe language" may not reduce the "safety" of SQLite^1

djb's software is also public domain and written in an "unsafe language", mostly the same "old and boring" one as used to write SQLite. Like SQLite it is appealing to many people and is found in many places^2

1. But the thoughtlessness and carelessness of an author, no matter what language they choose, is still relevant to "safety". In sum, "safety" is partly a function of human effort, e.g., "time, attention and testing", not simply the result of a language choice. Perhaps "safe" and "unsafe" are adjectives that can apply to authors as well as languages

2. https://ianix.com

Re: Why Is SQLite Coded In C

#385

Post by penberg »

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 actual reality is that I personally started the project because its synchronous architecture is holding back performance. You can read all about it in https://penberg.org/papers/penberg-edgesys24.pdf. The design is literally the next evolution of SQLite's architecture.

Re: Why Is SQLite Coded In C

#386

Post by penberg »

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.

The project is MIT licensed with a growing community of contributors. It does not even matter how long the company lives, all that matters is that some of the core contributors live.

Re: Why Is SQLite Coded In C

#387

Post by penberg »

frumplestlatz wrote: post #348
slashdev wrote: post #339

Earlier quoted context omitted.

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…

You're not wrong about VC-funded database arc, but what history are you even talking about?

I am sure you understand that I have absolutely nothing to do with Scylla's licensing. I have not worked there for four years nor was I ever in a position there that I would even had that opportunity to influence such decisions.

I am also sure you understand that Scylla's development model was completely different: they had AGPL license and contributors had to sign a CLA, which is why they were able to relicense in the first place. Turso is MIT licensed and there's no barrier to contributing and, therefore, already a much bigger contributor base.

I fully understand the scepticism, but you're mistaken about the open source history of Turso's founders.

Re: Why Is SQLite Coded In C

#388

Post by xiphias2 »

tomjakubowski wrote: post #175
wodenokoto wrote: post #23

I think it’s more interesting that DuckDB is written in C++ and not rust than SQLite. SQLite is old, huge and known for its gigantic test coverage. There’s just so much to rewrite. DuckDB is from 2019, so new enough to jump on the “rust is safe and fast”

If I'm remembering a DuckDB talk I attended correctly, they chose C++ because they were most confident in their ability to write clear code in it which would be autovectorized by the compilers they were familiar with. Rust in 2019 didn't have a clear high level SIMD story yet and the developers (wisely) did not want to maintain handrolled SIMD code.

I'm not sure it has changed.

Maybe autovectorization works, but can I just write a few ARM64 instructions on my Mac in Rust stable (notcexperimental/nightly) as I can do it in C/C++ by just including a few ARM specific header files?

Re: Why Is SQLite Coded In C

#389

Post by kneekoo »

wat10000 wrote: post #376
pjmlp wrote: post #360

Earlier quoted context omitted.

Whatever makes you happy to keep your view on the matter. https://bitsavers.org/pdf/apple/mac/Inside_Macintosh_Vol_1_1...

Now I'm wondering if you actually understand the difference between providing a Pascal interface and actually using Pascal to implement the stuff. That manual discusses the interface. I'm happy to change my view given evidence, but you have yet to provide a single word of evidence that there was any Pascal in the original Macintosh system.

[dead]

Re: Why Is SQLite Coded In C

#390

Post by throwawaymaths »

steveklabnik wrote: post #323
1vuio0pswjnm7 wrote: post #318

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…

"Broad strategy" is your words, not gp's. you are fighting a strawman. gp is just arguing that this is happening, and it's annoying.
Post reply on HN