You started out by saying 99% of web code is IO, then casually dropped down to 70-80%, as if that was the same thing. 20-30% of a huge codebase is still a signi

You started out by saying 99% of web code is IO, then casually dropped down to 70-80%, as if that was the same thing. 20-30% of a huge codebase is still a significant amount. I've never said IO is irrelevant to web applications. But that in my experience, those 20-30% or whatever can be important, complex and time intensive (the Word generation was actually one od the most time consuming parts of the last application I worked on) enough that fencing them off from the side effecting code in some way can pay off (one way to do this without going fully PFP is outlined here: https://www.jerf.org/iri/post/2025/fp_lessons_purity/#fp-pure-core---imperative-purifiable-core https://www.jerf.org/iri/post/2025/fp_lessons_purity/#fp-pur...). > First one looks like meta programming. IO. You are programming something else. I don't understand what you're saying. I was working on a document management system whose contents were stored in tree structures. These structures routinely had to be transformed into other structures. That's a very algorithmic task where the IO can be fenced off very easily (and should be fenced off if only for the sake of easier unit testing). This was literally one of the most common things happening in the codebase. > Chatbots are high IO. in the sense that every useful program has IO. Otherwise, there's a whole bunch of transformations and intent recognition and skill dispatch and what not that happens between the request and the response, and that can happen entirely in memory on one machine (it can also be offloaded wholly or in part to an external service like Amazon Lex, it depends on the use case, but even in the case where we used Lex we ran a bunch of manual transforms on the output for postprocessing). > The modern day method of coding these servers is to be non blocking as much as possible. Recent developments (e.g. virtual threads coming to Java) seem to indicate otherwise. Blocking code and non-blocking code are both valid for different types of scenarios. And offloading tasks asynchronously to a task runner doesn't mean that the code running those tasks doesn't have to be written. --- I really do think we've just worked on very different types of applications, and I just reiterate my point from above (and from the blogpost): There are enough use cases where clearly fencing off IO from algorithmic code pays off. If it doesn't for your use case, then don't do it.