1. Bandwidth requirements scale quadratically with player count, since the state of each player needs to be broadcast to every player. You can optimize this with clever tricks like server-side occlusion culling, but that's heavily dependent on your specific game's mechanics, and it still doesn't address the worst case scenario of lots of players clustering in a small visible area.

2. Players are not the only entity that need to be synced. Every server-side entity affecting a client needs to have its state broadcast to that client. A dynamically destructible environment that physically interacts with players is a perfect example of this - launch a rocket at a building, compute the Voronoi fractures server-side based on impact location, sync thousands of pieces of flying concrete debris (each with its own rigid body) across all players.

Pre-creating "sleeper" accounts is a common way of circumventing this, though it does require a degree of long term thinking/planning.

2. Sessions by definition are ephemeral. A database should not be necessary at all, an in-memory cache should suffice.

3. If you really need to distribute session data across multiple nodes, just propagate them asynchronously. Authentication and authorization are semantically idempotent operations. Having to possibly re-auth when making a cross-region request within milliseconds of logging in might be mildly annoying for the user, but consistency isn't a deal breaker here.

Does Spring Boot terrify you, then? Or Lua scripts in nginx? Or PHP? All of these use JIT compilation to run code that handles web requests.

Attack surface is a property of the JIT implementation, not of JIT itself. And eBPF is specifically designed to be very simple to implement and audit.

That's also why queues are inappropriate for addressing traffic spikes caused by market dynamics (celebrity news, sales events etc.). Those dynamics typically occur over the course of several hours, whereas a web request's latency SLA is on the order of several seconds.

[0]: https://en.wikipedia.org/wiki/Wickard_v._Filburn

The minimum duration for that qualification is one year. One year is nowhere near "long term" for a public works project. The Columbia shuttle took almost a decade to build. The interstate highway system took over three decades (and requires costly and ongoing maintenance).

> It shouldn't require socialism to get anything long term done.

What it ultimately requires is a trifecta of power (to fund the thing), vision (to plan the thing) and longevity (to see the thing through). Those three requirements could be satisfied by a government body or by a munificent billionaire, but democratically-minded people tend to put more faith in the former than in the latter.

Like any other tool, the quality of output is proportional to the quality of input. You'll get much better results if you provide specifics (detailed description of what you want, reference pictures, iterative clarifications etc.) and have it work on bite-sized pieces of the process (outlining, shading etc.), with manual verification and touch-ups in between. But all that still requires time, taste and experience, which deflates the "AI will replace skilled labor" hype.

> Government deficits are not caused by rich people. They're caused by the people you voted for.

I do not dispute this, but the deficit is exacerbated by a lack of tax revenue. Scrutiny will naturally move towards the people who are most able to fill the coffers.

> No, they're not. Their availability and price is determined by the Law of Supply and Demand.

I misspoke. What I meant to say is that the demand is fixed (i.e. inelastic). As you said, you can only eat so much - a poor person's subsistence will make up a much larger portion of their monthly budget than a that of a rich person.

Ribbing aside, the "rethinking" here sounds a lot like an AI-specific spin on the "bring the code to the data, instead of data to the code" paradigm. I imagine that the same multitenancy caveats of allowing arbitrary user-defined queries against a relational database (execution limits, access controls, etc.) will apply here as well.