Your restrictions sound quite challenging, good luck!

Last year I solved all the problems in C without external libraries [1] and I enjoyed it a lot. It forced me implement some low-level stuff that I had forgotten how to do (e.g. a heap) and to write some numerical routines myself (easier than you'd think!).

[1] https://github.com/sebastianotronto/aoc/tree/master/2023

Has anyone grown heirloom varieties in their home garden and is it worthwhile, e.g. does it taste good or is it more for the nostalgia factor?

The big reason for this is thermodynamics. A conventional internal combustion engine car has to convert chemical energy to kinetic energy - the absolute best theoretical efficiency of this might be 70%, but in practice it's more like 30%. Electric cars have to pay the same thermodynamic penalty, but they pay it at the power station (In practice, thanks to renewables, not all the electricity used to charge a car will come from hydrocarbons - but let's assume it does for ease of comparison sakes). It's much easier to build highly efficient hydrocarbon power stations - typical efficiencies range from 40-60%.

So when you look at the headline "efficiency" of an electric car, you need to take that thermodynamic penalty into account first.

A modern series hybrid like a Toyota Prius is effectively an electric vehicle and a gas generator (which means it has the same efficiency gains due to regenerative braking). That gets 52 mpg, which is about 493 Wh/km. If you generated the 225 Wh the Tesla needs in even the most efficient combined cycle gas turbine powerplant you'd need 375 Wh. Less - but not nearly as drastic as it first seems.

Renewables change the picture though - once you have significant renewable generation the carbon intensity of electricity starts dropping, which means that remote powerplant vs local powerplant argument falls apart. That is when the real power of electric vehicles kicks in - they can take their energy from anywhere.

Let’s not forget about big rocks falling from the sky, volcanoes and the Sun killing this planet inevitably in about 1b years from now. There better be a planet B at some point.

I think one of the biggest advantages of using Redis for job queing vs Postgres comes down to library support.

For example Python has Celery and Ruby has Sidekiq. As far as I know there's no libraries in either language that has something as battle hardened with comparable features for background tasks using Postgres as a backend.

There's a big difference between getting something to work in a demo (achievable by skimming PG's docs and rolling your own job queue) vs using something that has tens of thousands of hours of dev time and tons of real world usage.

I'm all for using PG for things like full text search when I can because it drastically reduces operation complexity if you can avoid needing to run Elasticsearch, but Redis on the other hand is a swiss army knife of awesome. It's often used for caching or as a session back-end so you probably have it as part of your stack already. It's also really easy to run, uses almost no resources and is in the same tier as nginx in terms of how crazy efficient it is and how reliable it is. I don't see not using Redis for a job queue as that big of a win.