barries11

"stall" is the best term I can think of as in "pipeline stall".

Better term, anyone?

Coincidentally, I recently looked at using CUE as a config file format, but it looked like it was too syntactically complex and unwieldy for them to edit compared to, say, TOML (which is warty-but-usable) or YAML (which is incredibly complex and has too many footguns).

Also, in order to work with it and to understand why their configs weren't working beyond simple error messages or worse, a config file that is technically correct but does something they don't want. To do that, if seems like they'd have to (a) understand unification, (b) be able to find and read the spec files, (c) overcome the syntactic similarity between data and schema, (d) be able to build mental models of why the data and schema combine to cause the symptoms they have. I decided to not use it for that purpose (yet).

I _want_ something like CUE, which is why I was looking at it, so...

Does anyone here have any real-world experience using it as a config and/or data format and ingestion engine for users that are _not_ complexity-loving CS-ophiles like myself who love nothing more than a cool new way of munging data?

ELI5 how this is Literate Programming? See the first example on https://en.wikipedia.org/wiki/Literate_programming for comparison.

CUE seems like the opposite: a typed data structure used to produce artifacts via a unification algorithm and feeding data to external tools to "render" those artifacts.

"hysterical porpoises" always makes me smile, and it's the benemalapropism I go for.

I don't disagree at all--p4 was kick-ass back in the day but the world, and our expectations, have moved on. Plus, they went all high-street enterprisey.

What makes it convoluted? Where did it lose the beat?

I used Perforce a lot in the 90s, when it was simple (just p4, p4d, and p4merge!), super fast, and never crashed or corrupted itself. Way simpler, and easier to train newbies on, than any of the alternatives.

Subdirectories-as-branches (like bare repo + workspace-per-branch practices w/git) is so much easier for average computer users to grok, too. Very easy to admin too.

No idea what the current "enterprisey" offering is like, though.

For corporate teams, it was a game changer. So much better than any alternative at the time.

We're all so used to git that we've become used to it's terribleness and see every other system as deficient. Training and supporting a bunch of SWE-adjacent users (hw eng, ee, quality, managers, etc) is a really, really good reality check on how horrible the git UX and datamodel is (e.g. obliterating secrets--security, trade, or PII/PHI--that get accidentally checked in is a stop-the-world moment).

For the record, I happily use git, jj, and Gitea all day every day now (and selected them for my current $employer). However, also FTR, I've used SCCS, CVS, SVN, VSS, TFS and MKS SI professionally, each for years at a time.

All of the comments dismissing tools that are significantly better for most use cases other than distributed OSS, but lost the popularity contest, is shortsighted.

Git has a loooong way to go before it's as good in other ways as many of its "competitors". Learning about their benefits is very enlightening.

And, IIRC, p4 now integrates with git, though I've never used it.

From the README (I'm not the author):

Important

sqlite-vec is a work-in-progress and not ready for general usage! I plan to launch a "beta" version in the next month or so. Watch this repo for updates, and read this blog post for more info.

Nice, I will definitely use these techniques.

Here are a few settings that make GNU make a bit faster, and enable multi-line, strict-mode bash scripts as recipes (make recipes are normally sequences of single-line sh invocations)--and enable quietude & tracing: https://github.com/barries/polling_state_machine_cpp/blob/ma...