Worst case in absolute time always requires ignoring pathological cases.
We don't care about worst-case latency in practice, and average case is often ignored as well. We look at 99.9% latency numbers or things like that. Worst-case is for people designing pacemakers or rockets, that's not what we are doing here.
Considering this code will likely be used in IoT, yes, this is what we’re doing here.
Nor is my sous vide machine or anything else I've seen as an IoT device. I wouldn't call say my oscilliscope an IoT device even if it can connect to wifi. It's a scientific device with cloud upload.
There was an interesting talk at the Chaos Communications Congress a few years back.
Gp post was not talking about security we're talking about Real time computing. If it's running on IoT hardware, eg rpi running linux, it's likely not doing real time os stuff because linux isn't really a real time os.
And I still don't classify pacemakers as IoT. Just because you want to slap a vague acyronym on any and every "connected" embedded device doesn't mean I agree.
That stuff is IoT in every definition of the word.
Monitoring might be fine, but installing something in the body that can kill you and then running it on node.js doesn't seem like a good idea.
...maybe an anonymous usage program?
...maybe their typical use case? (which is definitely not everyone elses)
...maybe the typical use case of Google employees using Go for their single-computer tasks? (which would be closer to a "typical user" as in people who read HN)
...an average of those three, or perhaps even more, use cases? wighted in some way?
But if done correctly, optimizing the 90% typical problem by 20%, gives you a general 18% improvement, far more than even making disappear the least important 10% of the runtime (which some bad optimization efforts tend to focus on...).
Making software faster is always about knowing where to work, and then focusing exactly on that. Nothing wrong in attacking the "typical [anything] case".
Pretty harsh for an informal post on a mailing list, its not like this was a formal proposal or an announcement.
Talking about why "typical" lacks meaning is fair, but calling the OP negligent is not.
You can't very well tolerate an "atypical" GC pause when you're firing a laser or radiation pulse, doing engine control, or even updating a display in a flight instrument setting.