The name Maestro has already been used for a workflow orchestrator which I worked on back in 2016. That maestro is SQL-centric and infers dependencies automatically by simply examining the SQL. It's written in Go and is BigQuery-specific (but could be easily adjusted to use any SQL-based system).
$ echo -n 'The SHA256 for this sentence begins with seven, seven, f, zero, a, b, b and five.' | sha256sum
77f0abb54cd09ad7b654bd5e762d7be58e7daffd1a0da6a56f5135bd667856a3 -
The details of how the data is stored are described in this 1979 paper by Douglas Comer: "The Ubiquitous B-Tree" [1]. Since it was invented, much hasn't really changed: practically all relational databases use some variation of this structure. I wrote about it in [2], which might help explain some aspects of how it works.
I remember the days when having to switch between x86, ppc, sparc, etc was a thing (not to mention the many flavors of UN*X) and we survived. In fact I think it was more fun back before the x86/Linux server domination. Architecture diversity is good.
I wouldn't rank glucose above fats. As I understand it, it's not exactly a "shorter battery" than fat - it is simply a form of energy that is abundant in plant life, but fat is still a (much) "better battery".
The reason our body always favors burning glucose first is NOT because glucose is "better" but actually because it is an inferior type of fuel (it creates "pollution" and is difficult to burn - you can develop diabetes from too much of it) - so our evolved system tries to get rid of it first, while hanging on to the "good stuff" for as long as it can.
If you are using BigQuery and your "workflow" amounts to importing data from Postgres/MySQL databases into BQ and then running a series of SQL statements into other BigQuery tables - you might want to look at Maestro, it written in Go and is SQL-centric, there is no Python dependency hell to sort out:
With the SQL-centric approach you do not need to specify a DAG because it can be inferred automatically, all you do is maintain your SQL and Maestro takes care of executing it in correct order.
My take on it is - just write for yourself. If, when you read it, it sounds like a good write up to you for whatever your own reasons are, that is all that's required. If no one else reads it, fine. But you might be surprised, a lot of other people may find it interesting as well :)
Subinterpreters existed from the very early days in the C API and were key to the implementation of mod_python (which I wrote). So if you used mod_python, you used subinterpeters without realizing it.
Github was cool when git was new years back - but these days, and especially given how git inherently is not centralized, it is not very clear to me why we all cling to github. With a little work, all that it offers can be done without any help of a centralized server/corporation.
I once submitted a blog post [1] and later received an email from someone at HN saying that it was a great article but didn't do so well and if I re-submit it, they will make sure it does better, so I did and it went to the top.
https://github.com/voxmedia/maestro/