Mere quadratic time complexity is something I would expect to timeout and catch at fuzzing time, as long as we do encourage non-tiny inputs, say 10K and beyond.
I agree with the 2 example tasks, which are not "simple" to write.
The remove-by-value snippet is 8 lines, and it can be wrong in a subtle way: if list contains pointers, then we have a memory leak beyond the slice final length (pointer values still exists within capacity, and objects are not garbage collected).
Author here: there were 2 initial use cases for me,
(1) I'm familiar with the language X but I forget e.g. how to "check if a file exists"
(2) I'm learning a new language Y, I know that "checking if a file exists" is a legit need and there must be an idiomatic way to do it in Y, so I look at the entry, alongside implementations in other languages that I'm more familiar with, so I can quickly spot the similitudes and the differences.
I do (1) all the time because my brain has very little onboard memory.
The website is open to contributions without prior validations. This means that not all snippets end up being both correct and idiomatic. I manually revert spam and "obviously incorrect" entries. For languages that I don't know very well, I encourage actual experts to fix snippets, or add a better new implementation, when they see poor contents.
See https://github.com/divan/txqr for this use case. Other probably exist. It can be useful sometimes to not bother with any network at all, e.g. an international museum machine streaming map and documentation for tourists.
Hi iainmerrick, just for info the measured per-file cost didn't include reading from the filesystem. Only the in-memory parsing was taken into account.
FWIW I really mean the "take the numbers with a grain of salt" advice, i.e. "Your mileage may vary". What I'm sharing in this article is not a bunch of hard, strong, exact numbers ; It's a journey and an invitation to apply similar reasoning process to your own use case and hardware.