The Uselessness of "Fast" and "Slow" in Programming
8 comments
·November 12, 2025shevy-java
> 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.
stevage
More useful words are "negligible" and "problematic".
IshKebab
> 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.
ncruces
More important, IMO, are the non-local effects of using CGO (vs. eg. Go asm), and which are harder to understand.
kragen
But what matters here is probably whether it's slow compared to the code being invoked via cgo, which is only true for pretty fine-grained APIs.
Lio
I mean, probably what really matters is how slow things are compared to the network latency of a HTTP request.
In web-development arguing about Go-Go vs CGo-Go times is probably inconsequential.
kragen
Latency and throughput are not interchangeable, and it is entirely normal to do millions of subroutine calls per HTTP request, so even if latency is your only concern, a subroutine call operation with a latency ten thousand dollars faster than the HTTP request might still be too slow.
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.