logical42

You didn't implement change data capture. You're using theirs.

I would love it if I could over-withdraw money from my bank account by having someone on the other side of the country take out money from my account at an ATM at the exact time as me, due to the fact that the bank's storage system was eventually consistent, but that's not the case.

That means they did implement change data capture, and only exposed it for a very specific use case.

Adding change data capture to a database isn't exactly trivial.

I agree with you, but you are omitting a key aspect of the problem which makes this hard. If you have a single server serving from a local sqlite database, caching and invalidating the cache is trivially easy.

It becomes way more difficult when you have N servers all of which could potentially serve the same data. Local caches could then, yes easily become stale, and even if you have a propagation mechanism, you couldn't guarantee against network failures or latency issues.

But suppose you have an HA redis instance that you store your cached data in. Even with a write-through cache, you basically need to implement a 2-phase commit to ensure consistency.

I am tempted to write a book called "The carnivore" though.

Well I guess I'm never going to be google-able again.

food scarcity could be viewed as a bin packing problem when you consider the amount of food that gets thrown away.

Counterpoint: Apple has been quite successful despite their insistence in silos across teams and orgs.

n64js is an n64 emulator written in (mostly) pure ES6 JavaScript. It runs many roms at full framerate.

Why?

Mostly for the challenge. [hulkholden] spent ~25 years (on and off) working on N64 emulators and writing one in JavaScript gives [him] the opportunity to expand [their] comfort zone and learn something new. It's a good showcase for how powerful modern browsers have become.

An N64 emulator written completely in javascript, so you can play N64 games in your browser.