Compare https://docs.firetiger.com with https://docs.firetiger.com/llms.txt and https://docs.firetiger.com/llms-full.txt for a realy example.

I think some of the reason is that there's so much coverage of writing SQL in its training set.

One thing that works very well is just giving it one or two example valid programs/statements in the custom language. It usually picks up what you're getting at very quickly.

When it slips up, you get good signal you can capture for improving the language. If you're doing things in a standard agent-y loop, a good error message also helps it course-correct.

The CRUD methods are great examples where we deviate from the AIPs.

It might better in the system throughput, and those benefits may even outweigh the misery put on that one person. But in the US, we largely sort that out by using cool-down times, hearings, and "community input."

Net result, according to my friend at least, is that bus stops feel _very_ sticky and hard to change.

Though, as you mention it's a big political ask (which is unfortunate).

I bet much less than half of the hundreds of HN commenters here bother to read it. Many are clearly unfamiliar with its content.

I am always reluctant to jump on with these independent ambitious projects. The first version is understandably rough, and the company seems to fold before they get to a second or third version.

But maybe advances in manufacturing in China are making high-quality, small-batch products like this more tractable?

I don’t know - it feels to me that this is evidence that there _isn’t_ sufficient demand to sustain a successful product like this.

(Small phones, unlike small cars, also have costs in UI development to maintain their form factor’s OS support, which can create an additional pressure to withhold devices for a viable and profitable market.)

Because it impacts ARPU. It's really not that difficult, you're the product being sold.

No, there demand is negligible. It's just typical hacker news people who want to suddenly become productive Silicon Valley trope hustle style, or people who want to change their damaging habits in a day, so instead of uninstalling TikTok which takes 15 seconds to do, they will spend money a separate device.

Although the keyboard may be useful.

This isn't really true. Your mock inplementation can embed the interface, but only implement the one required method. Calling the unimplemented methods will panic, but that's not unreasonable for mocks.

That is:

    type mockS3 struct {
        S3Client
    }

    func (m mockS3) PutObject(...) {
        ...
    }

Defining a zillion interfaces, all the permutations of methods in use, makes it hard to cone up with good names, and thus hard to read.

Lots of such frequently-quoted Go "principles" are invalid and are regularly broken within the standard library and many popular Go projects. And if you point them out, you will be snootily advised by the Go gurus on /r/golang or even here on HN that every principle has exceptions. (Even if there are tens of thousands of such exceptions).

Sounds much better than the interface boilerplate if it's just for the sake of testing.

"makes it hard to cone up with good names" is not really a problem, if you have a `CreateRequest` method you name the interface `RequestCreator`. If you have a request CRUD interface, it's probably a `RequestRepository`.

The benefits outweigh the drawbacks 10 to one. The most rewarding thing about this pattern is how easy it is to split up large implementations, and _keep_ them small.

    // embedded S3Client not properly initialized
    mock := mockS3{}
    // somewhere inside the business logic
    s3.UploadReport(...) // surprise