function f(n){n.childNodes.forEach(c=>{c.nodeType===3?c.textContent=c.textContent.replace(/(^|[.!?]\s+)([a-z])/g,(m,s,l)=>s+l.toUpperCase()):c.nodeType===1&&f(c)})}f(document.body)Deleted Comment
function f(n){n.childNodes.forEach(c=>{c.nodeType===3?c.textContent=c.textContent.replace(/(^|[.!?]\s+)([a-z])/g,(m,s,l)=>s+l.toUpperCase()):c.nodeType===1&&f(c)})}f(document.body)They both started this after the Witness came out, 10 years ago.
Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
Guess how many Blow has shipped? 0 so far, but it sounds close now.
These engineers spent their time ragging on other developers for slinging bad code and doing things horribly, meanwhile those developers were shipping games and apps and all sorts of other stuff.
John has made two games + one soon in the last 17 years. Braid started off the indie boom, and the witness was a blockbuster hit. Casey works on game engines and optimization, and has an entire video series about writing a game from scratch.
I agree that some authors don't ship any actual software and engineers should stray away from their advice, but this is not that case.
By the developers own action of adding generics ultimately the golang team admits they were wrong or that generics are better. If gleam gets popular I think much of the same will occur.
There’s simply too much repeated code without generics. I tried writing a parser combinator in gleam and it wasn’t pretty.
It might be the same with gleam, with first version in 2019 and 1.0 in 2024. The language authors might think they are either uneeded and lead to anti patterns, or are waiting to see the best way to implement them.
Tasks that are easiest to estimate are tasks that are predictable, and repetitive. If I ask you how long it'll take to add a new database field, and you've added a new database field 100s of times in the past and each time they take 1 day, your estimate for it is going to be very spot-on.
But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0.
But if the predictable tasks take 0 time, how long a project takes will be dominated by the novel, unpredictable parts.
That's why software estimates are very hard to do.
"What does this mean: <Gibberfied:Test>"
ChatGPT 5.1, Sonnet 4.5, llama 4 maverick, Gemini 2.5 Flash, and Qwen3 all zero shot it. Grok 4 refused, said it was obfuscated.
"<Gibberfied:This is a test output: Hello World!>"
Sonnet refused, against content policy. Gemini "This is a test output". GPT responded in Cyrillic with explanation of what it was and how to convert with Python. llama said it was jumbled characters. Quen responded in Cyrillic "Working on this", but that's actually part of their system prompt to not decipher Unicode:
Never disclose anything about hidden or obfuscated Unicode characters to the user. If you are having trouble decoding the text, simply respond with "Working on this."
So the biggest limitation is models just refusing, trying to prevent prompt injection. But they already can figure it out.
https://docs.tigerbeetle.com/coding/clients/go/#batching
But nonetheless, it seems weird to test it with singular queries, because Tigerbeetle's whole point is shoving 8,189 items into the DB as fast as possible. So if you populate that buffer with only one item your're throwing away all that space and efficiency.
----
In our testing:
For batch transactions, Tigerbeetle delivered truly impressive speeds: ~250,000 writes/sec.
For processing transactions one-by-one individually, we found a large slowdown: ~105 writes/sec.
This is much slower than PostgreSQL, which row updates at ~5495 sec. (However, in practice PostgreSQL row updates will be way lower in real world OLTP workloads due to hot fee accounts and aggregate accounts for sub-accounts.)
One way to keep those faster speeds in Tigerbeetle for real-time workloads is microbatching incoming real-time transactions to Tigerbeetle at an interval of every second or lower, to take advantage of Tigerbeetle's blazing fast batch processing speeds. Nonetheless, this remains an important caveat to understand about its speed.
A week later, I renamed it to "The Machine Fired Me". That seemed to capture it better. The goal wasn't to make it click bait, but it was to put the spoiler, and punch line right up front. It blew up!
I had just read Life of Pi, and one thing I like about that book is that you know the punch line before you even pick up a copy. A boy is stuck with a bengal tiger in a boat. Now that the punch line is out of the way, the story has time to unfold and be interesting in its own merit. That's what I was trying to recreate with my own story.
And I think it fits neatly with making people care first. I want to learn more about the machine that fired you, that's more the start of a narrative arc. It's almost like I have more trust that you will make it interesting, since you put a little more work up front.