It's a great example of what I think of as vertical integration for performance. As you go through the talk you can understand why all these abstractions exist and why they have to be so generic. But when you have a specific use case, you can vertically integrate from the problem definition all the way down to SIMD and reap big rewards.

Speed itself isn't the priority. You've got to ask what the direction is. If you're working on a project that is meaningful to you personally (maybe because it is very meaningful to others you care about!) then you'll want it to be done.

https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Runtime TDZ checks can be performance issues:

https://vincentrolfs.dev/blog/ts-var

Go is the perfect language for this new world. Its development loop is fast, it has types but not too much so, it is memory safe, it is easy to deploy and it runs efficiently enough for most line of business use.

Go was originally developed specifically for a world of interchangeable hard-working juniors, which is exactly what LLMs can scale up with only your budget as the constraint.

I'm wondering what advantage a hypothetical faster-compiling-Haskell would have in that world.

This is absolutely brutal to GitLab

I think you mean to say something like barrier to entry for contributors? Where having to sign up for a new service will discourage some engagement with the core repo.

https://linuxcontainers.org/incus/docs/main/explanation/cont...

Greatest hope: their approach catches on outside just Oxide, and I get to work somewhere with a similar ethos and practises one day.

Greatest fear: the way they work only makes sense for the most elite and well-capitalised of companies.

Mature ops would be tracking cache hit ratios right?

It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".

No, I think the article is not considering a utopian post-scarcity future. It's considering a fully automated paperclip future except the paperclips are bank balances for the 1%:

> corporations and banks do billions of virtual transactions every day with companies that have no product, no service, and not a single employee. The transactions and loans they move back and forth in off-shore accounts do not directly correspond to physical money, or gold, or any actual resource.

The argument in TFA as best I can tell is that "the economy" can be decoupled from "real things". I assume the trillionaire class would each have a few private farms to keep themselves fed, or just eat entirely synthetic produce - but their production needs would be tiny compared to the rest of this "economy" which would mainly be doing... something else?

I can't quite follow it, honestly - despite the author's arguments about what's logical, I can't imagine or believe in a sustainable system not intimately tied to real resources and production.

Even if the trillionaire class uploads their brains into silicon, that silicon has material needs such as electricity. Can't escape the material world.

But that's still not "abundance for all".

I can't see a way in CSS to detect the user agent preferred language, but you could do this in JS and add another attribute to the document or whatever.

If you're not yet in possession of a PDF somebody else gave you, and you aren't about to send something to a printer to make a physical copy... why would you bring a new PDF into this world?

This is what markup languages are for, and the most widespread format - readable on almost any device - is HTML.