The whole point is that the representation is learned. When you talk about various levels of abstraction, you're missing that all of these levels are representable with words and the relationships between them. That is verbatim what LLMs are optimized for. Interestingly, when you take an embedding, you do see that some transformations in embedding space actually hold which is quite interesting (e.g. tree + many ~ forest)

> Environment variables only deliver values

Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default.

> A string is not a schema

Yes, input validation is an application concern. The application should know what these values represent / how to parse them and error if they're invalid.

I could go on, but the article is all about trying to use a hammer as a screwdriver and complaining that the hammer doesnt work.

[1] If you take the slop and manually fix/improve/verify it to production value it can be immensely valuable.

It doesnt make sense to "own" a massage just the same way it doesnt make sense to "own" spectating a game in person. The video recording of people playing a sport is a good that you can own however. This is why an online/multiplayer game is harder to separate because it straddles the line of both a service and a good, but other cases are much more clear cut. (also, a quick google does reveal multipke open source diablo projects fyi)

Imagine a conversation with turns X, Y, and Z. When the LLM "reasons" about the next token A it does: P(A | X,Y,Z) and then P(B | X,Y,Z,A), etc. It will eventually produce a result P(D | X,Y,Z,A,B,C). Instead of continuing the context from X,Y,Z,A,B,C it continues it from X,Y,Z so you have P(N | X,Y,Z,D). This is what is meant by dropping the reasoning. This is done to save cache context for the session.

This is a different thing than preserving the K/V state of P(N | X,Y,Z,D).

The defense to training with copyright is that it is the same as how humans learn from copyrighted material. The storage or reproduction is a red herring. Humans can also reproduce copyrighted works from memory as well. Showing that machines can reproduce copyrighted material is no different than saying that a human can reproduce copyright material that the human learned from.

The defense to actually reproducing a work is that in order to do so, the user has to "break" the system. It is the same as how you can make legal software do illegal things (e.g. screen recorder to "steal" a movie)

None of this is to say that these defenses are correct/moral; but rather that this article doesnt add any additional input into whether it is or isnt.

Now that I think further, doesnt this also potentially break HTTP semantics? E.g. if the key is part of the payload, then a data.replace(fake_key, real_key) can change the Content Length without actually updating the Content-Length header, right?

Lastly, this still doesnt protect you from other sorts of malicious attacks (e.g. 'DROP TABLE Users;')...Right? This seems like a mitigation, but hardly enough to feel comfortable giving an LLM direct access to prod, no?

- Tiktok was not first. Before it was vine and youtube.

- Google was not first. Before it was yahoo and altavista.

Plenty of todays big companies were not the first in their area.

When you have a post with a like button and the user presses the like button, how do the like button props update? I assume that it would be a REST request to update the like model. You could make the like button refetch the like view model when the button is clicked, but then how do you tie that back to all the other UI elements that need to update as a result? E.g. what if the UI designer wants to put a highlight around posts which have been liked?

On the server, you've already lost the state of the client after that first render, so doing some sort of reverse dependency trail seems fragile. So the only option would be to have the client do it, but then you're back to the waterfall (unless you somehow know the entire state of the client on the server for the server to be able to fully re-render the sub-tree, and what if multiple separate subtrees are involved in this?). I suppose that it is do-able if there exists NO client side state, but it still seems difficult. Am I missing something?

The problem here is that there is no way to cleanly detect a conflict. The documentation talks about pages which have changed, but a page changing isnt a good indicator of conflict. A conflict can happen due to a read conflict. E.g.

Update Customer Id: "UPDATE Customers SET id='bar' WHERE id='foo'; UPDATE Orders SET customerId='bar' WHERE customerId='foo'"

Add Customer Purchase: "SELECT id FROM Customers WHERE email="blah"; INSERT INTO Orders(customerId, ...) VALUES("foo", ...);"

If the update task gets committed first and the pages for the Orders table are full (i.e. inserting causes a new page to allocated) these two operations dont have any page conflicts, but the result is incorrect.\

In order to fix this, you would need to track the pages read during the transaction in which the write occurred, but that could easily end up being the whole table if the update column isnt part of an index (and thus requiring a table scan).

I would love if this were upstreamed. Is there a github issue where you discuss the possibility of this with the rr devs? That might be something to add to your readme for everyone else who wants to follow along. Thanks!

This is a strawman. You're misinterpreting the word "serious". They are using it to mean scalable, not about unimportance/ability. At some point in the scaling process, it will be more effective to scale to another machine than stay on a single one at which point you need a lot of other primitives like the article mentions. E.g. a shared cache with proper invalidation mechanisms. If you dont need scale, then you're right, you dont have to worry about this. I will also note that it is slightly odd to use a framework like next.js if you arent (or planning on) running at scale because most of its features (e.g. SSR) are entirely performance oriented. Essentially, the whole point of the article is that despite being "open source" you cannot run next.js at scale yourself without a massive investment of your own.