That's super cool. I worked on Smyte and have wanted to replace the language with something very similar to what you're describing. I'd love to learn more about it.
I think it's a better and more terrifying plot if you watch it as a Kafka-esque dystopia where people are imprisoned by the machines for inscrutable reasons that no-one truly knows. Morpheus's power supply theory is then just a necessary rationalization and a part of the mythology that allows the resistance to continue, while being fundamentally incorrect.
Thermodynamic impossibility is a relatively minor obstacle for a true believer.
Me too. I always thought it would have been better if humans' processing cycles (thoughts) were utilised to supplement, validate and expand the Matrix. A sort of automatic, involuntary, unaware Mechanical Turk.
I almost alway use Que [1] now. It uses postgres advisory locks instead of Redis so one less dependency to worry about. You probably only need Redis if you're running a tonne of jobs.
If you're already using Resque (the audience for the blog post), you're already using Redis, so Sidekiq would make more sense. Additionally, a quick glance at the syntax for a que job appears that you'd need to change more code (I could be wrong), and the available UI seems to lag Sidekiq's.
Reading this: "Que's job table undergoes a lot of churn when it is under high load, and like any heavily-written table, is susceptible to bloat and slowness if Postgres isn't able to clean it up. The most common cause of this is long-running transactions, so it's recommended to try to keep all transactions against the database housing Que's job table as short as possible." I wonder what consistutes "high load". I throw hundreds of thousands of jobs atop Sidekiq often; if you're using the same database to manage your jobs, it seems that would dogpile your database (since each of those jobs is likely making db calls, and if it's a Rails app, you're typically using the same database)
