Does anyone actually compute / use this key feature? Or do you rely on implicit caching? I wish HN had a comment with a poll feature.

It would be important to use for relatively high traffic use cases

Let's say you have a chatbot with hundreds of active users, their requests could get routed to different machines which would mean the implicit caching wouldn't work

If you set the cache key to a user id then it would be more likely each user's chat could get cached on subsequent requests

Google Maps or any other aggregator has an inherent interest in market participant diversity. A lot of suppliers would mean competition, which results in ad spend, which result in higher revenue for the aggregator. Same with Google Search.

It's an interesting equilibrium point. They want local businesses to suffer enough to pay up for ads. But also not too much that they die. A good local business that does not need to advertise because it is simply good is actually a burden to the aggregator even though it is exactly what the end users want to see.

In the past, when I was a in position to build a search engine, we took the trouble of always including organically ranked results that were genuinely good, regardless of whether we got paid or not. I felt it was a long term investment into creating real value for our end users and therefore our service.

25 years ago Perl allowed you to express what was in your head 10x more concisely as in other mainstream language (which have since caught up with some of the features).

This was not the best when it came to others (or even yourself 6 months later) reading the code. But it was great for cranking stuff out that was simply too tedious in other languages.

What are some examples that you can’t express in json schema?

Anything not JSON

I wonder if these stay in the prefix cache?

Awesome experiment!!

I did a version of this where the AI writes tools on the fly but gets to reuse them on future calls, trying to address the cost / performance issues. Migrations are challenging because they require some notion of an atomic update across the db and the tools.

This is a nice model of organically building software on the fly and even letting end users customize it on the fly.

The trouble is not populating it. The trouble is that tables, even though structured semantically, give you absolutely no functionality. There are no search, filter, sort, or selection features that you get.

Compared to what? What gives you all that, and what prevents you from having it with tables?

Javascript arrays have functions for all of that, so if you use something like React and renders your table from data arrays then it's all pretty trivial. I guess the point is that if you have to use JS to do those manipulations, then at some point it's going to be easier to just the React(/Vue/Svelte/etc) approach than manipulating the table yourself using the API described in the article.

Frameworks that make development easy are inherently inefficient. If performance is priority, then you better sort it yourself.

countless plugins for use in countless frameworks. We should have all that built-in by now. like we finally have a functioning date picker.

A resource that would benefit the entire community is a set of ballpark figures for what kind of performance is "normal" given a particular hardware + data volume. I know this is a hard problem because there is so much variation across workloads, but I think even order of magnitude ballparks would be useful. For example, it could say things like:

task: msg queue

software: kafka

hardware: m7i.xlarge (vCPUs: 4 Memory: 16 GiB)

payload: 2kb / msg

possible performance: ### - #### msgs / second

etc…

So many times I've found myself wondering: is this thing behaving within an order of magnitude of a correctly setup version so that I can decide whether I should leave it alone or spend more time on it.

The pixel to sounds would pass through “reading” so there might be information loss. It is no longer just pixels.

Lots of caveats here in the following statement: if your application is not fully leaning in to frontier model capabilities, you are probably building a previous generation product.