> The question I’m talking about here is, is “slow”, as a word standing by itself with no further characterization, even an applicable concept?

Yes, because there's usually context. To use his cgo example, cgo is slow compared to C->C and Go->Go function calls.

> A software engineer may be slicing and dicing nanoseconds

People typically live only once, so I want to make the best use out of my time. Thus I would prefer to write (prototype) in ruby or python, before considering moving to a faster language (but often it is not worth it; at home, if a java executable takes 0.2 seconds to delete 1000 files and the ruby script takes 2.3 seconds, I really don't care, even more so as I may be multitasking and having tons of tabs open in KDE konsole anyway, but for a company doing business, speed may matter much more).

It is a great skill to be able to maximize for speed. Ideally I'd love to have that in the same language. I haven't found one that really manages to bridge the "scripting" world with the compiled world. Every time someone tries it, the language is just awful in its design. I am beginning to think it is just not possible.

More useful words are "negligible" and "problematic".

Often, a user presented with a progress bar will wait much longer without frustration than a user without one will do. Sometimes, making the code faster is non-trivial and is not cost-effective when compared to making the user simply not complain.

> Most people, most of the time, doing most web work, are so thoroughly outclassed on speed by their web framework and server that the speed of their choice is irrelevant. Which means they should be selecting based on all the other relevant features.

I disagree with that as the choice of framework doesn't impact just the request/response lifecycle but is crucial to the overall efficiency of the system because they lead the user down a more or less performant path. Frameworks are not just HTTP servers.

Choosing a web framework also marries you to a language, hence the upper ceiling of your application will be tied to how performant that language is. Taking the article's example, as your application grows and more and more code is in the hot path you can very easily get into a space where your requests that took 50ms now take 500ms.

I think people tend to overestimate how much certain choices matter for performance. But I don't agree that the speed of frameworks doesn't matter in most cases. To me the base performance of such a framework is essentially like a leaky abstraction. The moment I hit any bottleneck I suddenly need to understand how the framework works internally to work around it.

I'm unlikely to get bottlenecked on well written and idiomatic code in a slower framework. But I'm much more likely to accidentally do something very inefficient in such a framework and then hit a bottleneck.

I also think the difference in ergonomics and abstraction are not that huge between "slow" and "fast" frameworks. I don't think ASP.NET Core for example is significantly less productive than the web frameworks in dynamic languages if you know it.