3 ms·

So here's a real-world case of where this actually does matter: https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/20

So here's a real-world case of where this actually does matter: https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... two minor follow-ups on that as well: * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-rust-continued/ https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... * https://andre.arko.net/2022/03/13/parsing-logs-faster-with-rust-revisited/ https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...

WJW 4y ago
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.