> The higher-order function style also tends to be much slower, so when writing a loop there's a decision burden every time between saving a line or two and writing fast code. (TIMTOWTDI is not really the Go ethos.) And programmers usually prefer concision, so the net result is often slow, HOF-heavy code.
This is very real. We do it all the time in JavaScript:
Not once do I think about how many things are initialized, iterated over, etc. Rarely would I do something like this in Go.
Whether it matters is a good question, but the point is true: language facilities make you care more or less about performance depending on what it does.
This is very real. We do it all the time in JavaScript:
Object.entries({...spreadMerge, ...secondSpread}).map().filter().find(x)
Not once do I think about how many things are initialized, iterated over, etc. Rarely would I do something like this in Go.
Whether it matters is a good question, but the point is true: language facilities make you care more or less about performance depending on what it does.