https://matthewbutterick.com/extinction-level-capitalism.htm...

The main reason was to avoid a separate cron job, but it had other benefits (and downsides) too. Something like:

    DELETE FROM foo WHERE expires_at < now() LIMIT 10;
    INSERT INTO foo .....;

And by deleting (up to) 10 each time we insert one, it ensures obsolete things will eventually get deleted.

Obviously, this isn't viable when the deletions must happen due to strict policy (e.g. legal compliance) since it can't ensure when things get deleted, just that they eventually do. IIRC, in my case, I used it for a password reset tokens table. There's no legal issue there and keeping expired ones around is fine as long as the code also checks `expires_at` to make sure it's still valid (which would be a good practice regardless, for defense in depth).

Storing some data in a binary file isn't very hard. Making it so that you can do quick lookups on it (indexes) and implementing joins in a sane way is kinda hard, but easy compared to the real problem:

Ensuring ACID (in the case of "traditional" databases). I.e. Atomicity, Consistency, Isolation, Durability.

You need to protect against data corruption in the event of failure, all while guaranteeing atomic operations at the user level concurrently (in most production DBs; SQLite is a notable exception in that it fully serializes writes --- but it can get away with this because it's an embedded database with the primary use case of a single-process writer). And the entire thing must land on a known good state at the end of all of those concurrent transactions.

... and they must do it all while maintaining good performance, and sometimes on a combination of filesystem + hardware that's actively hostile towards the idea of data integrity (e.g. hidden RAM caches in disk or RAID controllers that don't flush on power loss --- thankfully, those are getting rarer, or so I've come to understand).

Anyway, as it turns out, while the STL container situation is better than it was, it's still really terrible performance-wise.

So even nowadays, you're better off writing your own containers for performance-critical tasks; the benefits can be in orders of magnitude (depending on the task at hand, of course).

Hell, I'm forced to use such software at work because we're (at least for now) stuck with a horrible legacy vendor.

It is not fun. So, no, "just show it to the userand let them decide" doesn't actuality resolve anything either.

It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feels that way. (I suspect the truth is that they were consulted, but ignored.)

It means codegen needs to resort to all sorts of hacks (like the relooper) in order to target WASM, a property not shared by any other target.

And apparently, the way they handle variables also results in deoptimization, though I don't recall the details of that.

Add the fact that interacting with the browser on the web still has to go via JavaScript to this day (for the most part, at least), and, well.

---

TL;DR a combination of poor IR design that has a massive impedance mismatch with pre-existing compilers (and most new ones, because it turns out there's a reason the WASM approach isn't standard) plus WASM still being a second-class citizen in its supposed primary environment (the 'W' in WASM) --- the former ensures targeting it consumes a lot of resources/time, the latter ensures the bar for that to be worth it is much higher.

You can target most architectures with little trouble (at least a a baseline --- optimization's a hard problem regardless of target, except maybe SPIR-V due to the recommendation that pre-optimization is limited in scope). But WASM is completely out there, it's closer to trying to target e.g. Java (not JVM!) at the backend instead of machine code or some other IR.

You don't make an IR intended to be targeted by existing/native compilers by making it completely different to anything they had to target before and completely different to their own IRs and representations ... unless you're the guys behind WASM.

Typora & Obsidian apply the same ideas to Markdown.

I do think WYSIWYG is an absolutely broken paradigm for anything outside of literally just desktop publishing --- but WYSIWYM has a lot of merit.

Enough that I've been working on a stand-alone Markdown editor component that takes ideas from Typora et al.

Think (for example) using a pluggable PBR module in this way, where you give it a config/options struct instead of a weird combination of `#if`, runtime arguments, and predefined uniforms and/or function names.

C makes it much better than C++ in that the designated initializes can be set in any order --- so I don't need to remember the often-arbitrary order of struct fields for the options struct.

I find it weird that C++ took this great C feature and kneecapped it ...

I got everything setup correctly, but Microsoft seems insistent on silently dropping my email.

Keep up the good work!

It would avoid the whole mess of block vs table vs float vs flexbox vs grid (and also absolute vs relative vs fixed) positioning.

Basically, it feels like 90% of CSS is it trying to fix its past layout mistakes & limitations.

Jira is absolutely huge, so it's hard to tell what parts of it you're interested in.

Alas, that never materialized as the in-person campaign I was DMing fizzled out.

Its IR design is horrendeous.

Or, for that matter, Ukraine giving up its nuclear capabilities.