Emphasis on "the equivalent".

Further down he writes:

> I am of course using sanctioned cheating: I get all those tokens because I'm an individual, with the Claude Max discount. So it "only" costs me about $5k/month out of pocket, for a 50-agent cluster running on a 512GB M3 Ultra Mac Studio I bought off eBay for $25k.

> So it's not $120k/month of real money, but it's still crazy spend.

I've only skimmed the book and even though it was clearly written with the help of AI, there is some very good (and for the Python world novel) stuff in it. I particularly liked the chapter on effects.[0] I very much share the author's opinion that properly managing effects is the future:

> The history of programming is a history of scaling barriers. Each time, the pattern is the same. Something the programmer tracks by hand works fine in small programs. Systems grow until hand-tracking fails. The solution moves that tracking into the language or the toolchain, and a generation later, nobody can imagine doing it by hand. […] Effects are the barrier we are inside right now, which is why it is hard to see.

[0]: https://thinkinginpython.com/44_Effect_Management.html

Think fine book is pre AI era

Or street numbers? https://www.456bereastreet.com/ used to be a classic.

GrapheneOS heavily restricts JIT usage, too:

> - Android Runtime Just-In-Time (JIT) compilation/profiling is fully disabled and replaced with full ahead-of-time (AOT) compilation. The only JIT compilation in the base OS is the V8 JavaScript JIT which is disabled by default for the Vanadium browser with per-site exception support.

> - Dynamic code loading for both native code or Java/Kotlin classes is blocked for nearly the entire base OS. […]

> - Dynamic code loading for both native code or Java/Kotlin classes can be disabled for user installed apps via 3 exploit protection toggles: […]

https://grapheneos.org/features

If you're already using a Pixel, why base your custom, very much stripped down version of Android on LineageOS as opposed to GrapheneOS? From a security perspective, that's insanity.

(I would actually love to see a GrapheneOS-based version of this!)

> I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these.

While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.

A lot of vibe-coded GUIs aren't fast, so this particular issue changes nothing. You're describing a property of the software development method, not TUIs vs GUIs.

> First, a TUI is usable with only the keyboard.

Is it? Many TUIs these days don't allow me to configure my usual key bindings for moving my cursor within input fields. Meanwhile, GTK offers (used to offer) a way to customize key bindings across all GTK applications. (Unfortunately, they removed that feature in recent versions. Now I understand why people always get so upset about the GNOME devs…)

Do they? https://longbets.org/1/ has yet to be settled. Either way, I doubt an LLM could fool anyone here who who knows how LLMs work into thinking it is human, at least not for an extended period of time (think about context length/compression, prompt injections, …).

You'll notice those goalposts are substantially stretched from the original test.

How so?

This was what stood out to me, too! And this:

> Packfiles are the fundamental building block of Git storage and Git networking.

(emphasis mine)

> His approach was storing the objects in a distributed hash table. This was only possible thanks to JGit, a custom Git implementation in Java. Like any good ol' Java library, JGit provides enough interfaces and factories and interface factories to abstract all the details of a normal Git repository, including replacing its on-disk packfiles with a DHT. Although the system worked and results were good enough for normal Git operations, the limitations of the Git protocol (which again, require packfiles to be sent over the network regardless of how you store data on the server) made the git clone performance bad enough to discard the design altogether.

Looks like Java enterprise design patterns aren't all bad after all :-) and the git ecosystem would have profited from a bit of abstraction and separation of concerns here, where network protocol, git domain model, and storage layer are evolved somewhat independently. The domain model is what everyone in the ecosystem needs to agree on, the network protocol is what at least the given local & remote host need to agree on, but storage is mainly a local concern.

Of course the question is whether git would have today's market and mind share if they had gone down that path. The ecosystem would be a lot more heterogeneous, evolving network protocol would probably take much longer, etc.

Agreed, I was excited about this until I found

  To get started, sign in with Vercel:

  fx login

in the README on Github.