People of different ethnicities can differ by something as minor as just language and language-related culture, such as for example Czechs vs. Germans. So surely ethnicity is not the applicable term here.

I'm surprised that Interbase/Firebird seems to be entirely omitted from this despite pioneering the MVCC approach.

OP here, I acctually had Firebird listed in some version of my draft, but had to make a natural cut somewhere.

I see. I guess that makes sense, popularity-wise. I imagine the results were in the vicinity of PostgreSQL anyway, considering the similarity of approaches.

I had to make a cut - and that's also a reason why etcd got mentioned - focused on what most people today know.

but that approach doesn't teach "most of your audience" something new that they didn't know before

well, let's say it depends what audince. This particular topic came as part of talks I deliver on Postgres internals and my webinars. Same story. Again and again.

But I do get the point. Here the goal was - there's no perfect solution. Just characteristics to be aware of.

Given the anti-LLM sentiment here I need to get offline and not get affected by it.

Your post has a trove of really good data. A lot of care, skill and attention must have gone into building that kind of expertise. When you then use an LLM to produce a post about it, that comes off as lazy. It wouldn't have to be that way, but sadly very (very!) often is.[0]

Writing well is hard. Editing text to be readable is hard. Shortcutting that process is a signal to your audience that you do not appreciate their time. I use LLMs at work to generate client-facing analyses, but I never let a single version go out without doing at least some revising. LLMs love nothing more than to generate another token, which makes their output flowery and verbose. They overuse rule of three, without any of the underlying understanding why it works, let alone when (and how) to break it intentionally.

I spotted the familiar "seesaw cadence" in your post but ploughed through because the content itself was still damn good. It's a shame that you did not put the same level of care into your writing that has gone into developing the technical expertise. Getting the post flagged because of the generic anti-LLM sentiment is undesirable but expected. HN doesn't have a way to mark posts as "sloppy writing but content-wise really good".

It's the same kind of visceral reaction this crowd tends to have towards voice notes: "if you did not bother to condense your thoughts and instead dumped half an hour of rambling for me to dig through, why would I waste as long to listen to you not being able to say it clearly?" ["Podcast for none"]

0: The only exception I can point to is https://nearzero.software/p/warranty-void-if-regenerated (discussed at the time in https://news.ycombinator.com/item?id=47431237).

> As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all

The byte code compilation option is described in CMUCL documentation, section 5.9 Byte Coded Compilation: https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation....

Ah, with how cmucl was problematic to get running I never delved that deep. It indeed is not present in SBCL.

That said, as mentioned, it gave no real impact on bootstrappability nor portability

I simply assumed the tables in question were log tables. (No, not that kind of log.)

I found very quickly an NYT article from 1993 that listed his date of birth as "April 5, 1952". I don't know if that's the source for the Wikipedia article but that info has been around for a long time, it seems.

You can simply check Wiktionary, like you can with most words.

No, database servers solve that problem. That the unnecessarily COBOL-like SQL ended up being the primary interface to them is simply an unfortunate accident of history.

There have to be some limitations on the language for this to work. For example, there must be no way to specify a neverending loop or to lock something and forget to unlock, an so on.

If you want to make ultra-complicated clients, I assume that's what WebAssembly is heading towards. And it doesn't limit you to a poorly evolved language that wasn't intended for ultra-complicated software in the first place, or even force you to use that poorly evolved language on a server if you need to run the same logic in both places.

You're moving the goal posts.

It was originally about build steps but now you're talking about it's design.

And your only response is to use a technology years away from being practical for most web apps?

Jevons' paradox still exists. Making X cheaper (usually by needing fewer people to do one unit of X) can and often does lead to more people being needed for X.

Merchant shipping contributes around 3% to CO₂ emissions. That is smaller than, e.g., electricity and heat generation, road transportation, manufacturing, construction, and agriculture.