And then then the fast lanugage implements caching.. Your first point is valid

The language does not implement caching. Your application architecture needs to take server caching into account.

And in my experience, devs who focus so much on the "fast language" part, do so, because they don't actually know much about caching. And no, this statement is not universally qualified.

With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy.

However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.

I don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.

You don't implement HTTP caching, except in very specific cases.

You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.

Of course "you don't implement caching". I think it was clear that I was talking about designing a cache-aware application.

Cf. http://www.mnot.net/cache_docs/.

Yes, and I was talking about implementing caching of components used to compose the pages and API responses, not a full HTTP cache tier that has to be placed in front of your application.

Okay, then I misunderstood where you were getting at. My fault.