Biggest design bug imo is the workers need to register for the workflows they support, but will happily pull tasks from unrelated workflows if they're on the same queue. No way to put failed tasks back into the queue again either.

Isn't split stack architectural, i.e. client heavy vs thin client. Not a hard TS feature?

With Phoenix you can write actually 0 code that runs on the client, just the backend and html templating.

I'd say cue is nicer, but the tooling available is even less mature.

"appreciation"

My phrasing was just to point out things moving in the opposite direction to what has previously been considered normal (which is also the economically intended 'normal').

Me too! I got interested in category theory and how to express a logical model of "workflows" as a category. Then ai told me workflows are a monoid and not to bother.

I note the absence of a motivation.

Is there no upstream package repo like docker has.

That's objective metrics. Not an objective way to compare, which is the selection of metrics to include.

That's exactly why there's a ton of different benchmarking suites used for evaluating hardware performance.

I reckon we'll have similar suites comparing different aspects of models.

And, at some point, we'll be dealing with models skewing results whenever they detect they're being benchmarked, like it happened before with hardware. Some say that's already happening with the pelican test.

> I reckon we'll have similar suites comparing different aspects of models.

The problem is that hardware benchmarks are harder to game. Yes, hardware manufacturer can make driver tweaks for say particular game to run better but the benchmark is still representable for the workflow user faces and they can't change the most important part, hardware, they can't benchmark gimmick their way in designing hardware

Meanwhile in LLM land the game is to tune it for the current popular set of benchmarks, all while user experience is only vaguely related to those results

I like starting most of my projects on marimo notebooks now and slowly moving parts of it to the main codebase + db.

By the end of it I might remove the notebook entirely but usually I keep it for some visualisation + running stuff as a cli tool.

Strange advice not to push the mega merge. It's what I call my release branch.

One thing I like is there's many ways to achieve the same result. E.g. author uses a fancy rebase to graft a new branch between trunk and merge point. I could do the same by: 1) rebase -s onto trunk, 2) merge new branch with mega merge, 3) squash old megamerge upwards into new merge. No cryptic revset needed.