I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.
I've had my hair on fire because my app code shit the bed. I've never ever (throughout 15 years of using it in everything I do) had to even think about Postgres, and yes, I always set it up self-hosted. The only concern I've had is when I had to do migrations where I had to upgrade PG to fit with upgrades in the ORM database layer. Made for some interesting stepping-stone upgrades once in a while but mostly just careful sysadmining.
Their trackrecord is such that if I got a similar call my first question when possible would be how I was being reimbursed. They are welcome to fork anything of mine if they observe the license attached. I will take a look at any PR. I will NOT spend time explaining anything to their engineers unless reimbursed at my regular rates.
Backblaze can lose 3/20 hard drives and still recover the data from parity drives. They don't have to rely on recovering it from non-operative drives unless they become unbelievably unlucky.
I had an insight when learning about the Halting Problem. There is a class of programs for which the Halting Problem is solvable since you can use circuit analysis to see if well-formed loops halt. We should strive to write programs in that class since then we know that the execution, long as it may be, will yield a result.
I found after starting to apply mise en place that when I wasn't doing it I was still quicker than before. I fetched more things from each cupboard or fridge when I opened them, even if I wasn't measuring out the item into a container beforehand.
I wonder if you could get the intended result for any language with a simple ruleset. You don't need a language to reduce/eliminate miscommunications, you need intent and understanding.
You have the right comparison. Developers need to remember that nobody had a job punching holes in cards after the revolution of personal computing. Going to be the same here. The jobs will revolve around operating the new "loom" which we have been given.
Difference is that compressive strength generally decreases over time. Here we have a product where it increases over time. Changes the equation on how you build and maintain it.
I'm working on something where I need to basically add on the order of 150,000 tokens into the knowledge base of an LLM. Finding out slowly I need to delve into training a whole ass LLM to do it. Sigh.