It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).
Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that.
In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.
I appreciate that there might be use cases where performance absolutely does matter, and log parsing is indeed one of the sweet spots for that. But offline analytics is something quite different than HTTP request generation, even if you sometimes do both in an AWS lambda.
Additionally for the case mentioned, the log parsing apparently already fit quite comfortably in the free tier of AWS lambda. Rubygems.org seems to get its developer time for free, so Andre can keep tuning this log parser as a hobby experiment (in the best sense of the word, nothing wrong with having fun). But TFA was about building a startup and most of those definitely don't manage to get their devs to work for free.
