The GTA fix shows humility, literally the first sentence of the "recon" section is "First I wanted to check if someone had already solved this problem". Geohot wasn't interested in if anyone had tried and failed to "solve search", or why it might be a difficult problem. He assumed that Twitter were a bunch of idiots.

The whole approach of the GTA fix author is curious and humble. Very low ego.

Comma does some cool stuff, if relatively entry-level, and this post is good napkin-maths and was a fun read, but there is so much more depth and a hundred ways in which this post is wrong or over-simplified to the point of near irrelevance.

It can back on to git if you want, so a migration doesn't have to be all-at-once. It already has all of these features and more. It's stable, fast, very extensible.

jj truly is the future of version control, whereas git plus some loosely specified possibly proprietary layer is not.

I'm excited to see what ersc.io produces for a jj hosting service and hopefully review UI.

TINAD didn't stick with me at all beyond the time I spent reading it, whereas Ra did in a way.

I've never liked Go, but its strengths are absolutely compiling to single binaries, fast compile times, and concurrency primitives (not necessarily using them) etc. Compiling to Go is a great idea.

What sorts of searches are you doing? My guess is this really matters and that you're using search for a completely different purpose to me, but I don't know what that is.

I mostly watch videos from my home feed or from channels I subscribe to. When I search it's almost always either:

- film/game trailers I've heard about and want to find (e.g. gta vi trailer)

- videos I've watched before but maybe not liked, with a channel keyword and maybe video keyword (e.g. tom scott bell), or music

- tutorials, where I don't really care about the specific video, I care about the outcome (e.g. how to remove roller blind)

In all of these cases search seems to nail it. The trailer is always the first result (but could be from a variety of sources), the recall on videos I've seen before is basically perfect, and the tutorials get me to the right outcome.

Are people using search for discovery, like putting in a vague topic and trying to explore a topic from search? What specific kinds of queries does it do badly at?

That's the reason I think it honestly depends more on the complexity to understand and the necessity of having a mental model of the code.

If the table stakes for using my API is a local GPU to build the interface, my competitors who used their GPUs once to create the interface for their customers will win. If the API getting started guide involves going to a user-contributed list of prompts to put together a set of things I want in the interface, the competitor who doesn't have that step and provides a default interface will win.

Default interfaces being provided is not going to change, and the universal truth of defaults is that most people stick with them.

Power users modifying their interfaces has always been a thing and is easier with LLMs, but it's going to remain niche, as in, something that power users/hobbyists do, or companies might provide their own internal UI to some external API, but again that already happens extensively.

Amazon is the wrong analogy I think, because delivery is in some ways cheaper than every individual going to the store themselves, storing in warehouses is cheaper than storing in stores. In fact in some ways the Amazon analogy better fits the other way around. Not a perfect fit.

Imagine policy compliance too? You need a cookie banner for legal reasons, how do you enforce that everyone's interfaces add the cookie banner? I hate cookie banners, but it's a clear example of where compliance dictates UI, and there are others (sales, insurance, contracts, etc).

As for costs decreasing, sure, and local LLMs improve things... but building the UI once will always win out on costs. Even with local LLMs we'll still cache UI creation, so then why not share that cache? Maybe it takes a bunch of prompting to get the exact accessibility stuff you need in the UI, so now you share prompts for generating the bit you need.... why not just share the actual output, why not just use the one the service provides?

I think there's a version of this focused on customisation that I can see happening, but otherwise all I see is a ton more code, a ton more liability, and products being on the whole worse.

1. Branding. Companies want to control their interfaces for all sorts of reasons. Branding is a big one. Clarity and comms are another.

2. LLMs in the hot path. LLMs are expensive, a hell of a lot more expensive than executing some Javascript locally. Hell, you'd still probably need to do that under this model anyway. We're likely to see LLM usage filter into the right places, use-cases with higher leverage, LLMs to create a UI that is shipped to all users over LLMs creating UI on the fly every time. Costs and time will dictate this just like they have dictated how every other technology is used.

The main problem is the dynamic scoping (as opposed to lexical scoping like most languages), and the fact that lots of things are untyped and implicitly referenced.

This is definitely partly training data, but if you give an LLM a simple language to use on the fly it can usually do ok. I think the real problem is complexity.

Go and Java require very little mental modelling of the problem, everything is written down on the page really quite clearly (moreso with Go, but still with Java).

In GCL however the semantics are _weird_, the scoping is unlike most languages, because it's designed for DSLs. Humans writing DSL content requires little thought, but authoring DSLs requires a fair amount of mental modelling about the structure of the data that is not present on the page. I'd wager that Lisp is similar, more of a mental model is required.

The problem is of course that LLMs don't have a mental model, or at least what they do have is far from what humans have. This is very apparent when doing non-trivial code, non-CRUD, non-React, anything that requires thinking hard about problems more than it requires monkeys at typewriters.

These plans vs API keys issues are exactly the same concept.

You are the reason these changes are happening. You may well be the reason that subscription prices go up.

Similarly, on a home internet connection you might pay for a given size of pipe, but most residential ISPs don't allow running publicly accessible servers on your connection because you'll typically use way more of the bandwidth.