I just spent a full hour basically telling someone not to use filter as forEach

You're doing the Lord's work, good sir, don't be discouraged!

@spongessuck I don't know about that but right now, I need to do some other work...

Thanks for you kind words, my friend.

filter as forEach? 🥴 how? why? I mean it… technically works, but…

I wonder if map() function can be used similarly (foolishly)

on a second thought, filter in best case scenario should be as quick as forEach, worst case scenario it will be more memory-intensive

I wonder if there is a language where there is a very specific corner case where you can win something by using filter instead of forEach

Fun fact: plain old for loop in js is almost always quicker than forEach, especially in V8-based environments

@kiki considering that functions are the main building blocks of JS, this is quite pathetic. 😄

@Lensflare you have a huge array you wanna iterate through? Use a for loop. Nothing pathetic about it.

@kiki sure but if JS is practically built upon functions, you’d expect them to be extremely optimized.
It’s generally a bad sign if you need to worry about performance when using the very basics of a language.

Also, readability should be the most important factors when deciding if to use for or forEach.
Otherwise you sacrifice readability for performance because of some language specific detail.

@Lensflare when you have a really long array, every language will struggle. For loop is the most efficient way to iterate over arrays in js. “Built upon functions” is the most basic explanation that is “right” only when you look at the API on MDN. Under the hood, there are a lot of optimizations in V8.

@Lensflare familiarize yourself with the concept of Big-O. It will make you a better engineer and may help with magical thinking about some languages being “faster” than others. I've said everything I wanted to say, not just to you, but to everyone else reading this in the future.

@kiki seems like you should familiarize yourself with big-O, not me.
In terms of time complexity, for and forEach and anything else that just iterates once, is the same.

I’m not even talking about different languages being faster or not.
I’m talking about JS having differently performing ways of iterating.

I admit that I don’t know if other languages are similar it that regard, but I assume that if there is a difference, it’s probably negligible.

It might be negligible in JS, too, I don’t know. I just take your word for it that it’s not negligible because you said that you should pick for for better performance on large data.

@kiki "when you have a really long array, every language will struggle"

Rust be like 👀

@12bitfloat are you namedropping popular and hyped language for internet points, or are you really not familiar with algorithmic complexity? Or both?

@kiki The only one here not seeming to understand much of anything is you

You said every language has a problem when iterating over large arrays using map reduce style code instead of a for loop

That's just wrong. Rust (and C++) can aggressively inline all that, resulting in no performance difference and often identical codegen

Also none of this thread has anything do with algorithmic complexity. Like @Lensflare said, it doesn't fucking matter how you linearly iterate over an array, it's still linear

@12bitfloat sigh
1. 2 million items array slow and you can’t engineer it away because big o
2. In js specifically, for fasta than foreach. May not be the case in other langs

Here, dumbed it down for ya

@kiki Sorry, I don't speak slow dynamic language

Also you're the one that brought up big O and fell on your nose, don't try to weasel your way out of it. None of this has anything to do with complexity

@12bitfloat my code is used by 500,000 people as a direct dependency

yours isn't

this means whatever you say about code doesn't count, and you can't possibly have any qualification to talk about bigo and whatnot

@kiki Appeal to authority fallacy

Also cope

@12bitfloat sorry, come back when your bLaZiNg fAsT 🤡 code is relevant in open source

till then, you can't even be talking to me

@12bitfloat you're probably a type of guy to google logical fallacies beforehand to argue on the internet

bye sweetie 🥰 no hard feelings

@kiki wow. I’m not sure if you are trying to be sarcastic or you actually mean it but this is one of the most arrogant things that I’ve read.

@kiki I'm an engineer, when people are wrong I like telling them how and why so they can better themselves. Your loss I guess

@kiki sorry in the case that you are trolling, but your last comments picture you as a person that is just horrible to talk with and that is a very polite way to phrase it.

@12bitfloat okay, “engineer”. Here are facts without any fallacies:

me: “when you have a really long array, every language will struggle. For loop is the most efficient way to iterate over arrays **in js**”

you: “You said **every language** has a problem when iterating over large arrays using map reduce style code instead of a for loop. That's just wrong. Rust (and C++)…”

I said JS will struggle with mapReduce style. You accused me of saying **every** language will struggle with mapReduce style.

Let's see if you're honest with yourself.

@kiki You should start every sentence like this from now on: <<okay mr. """engineer""">> i like that

If I read it correctly your argument is that you should use for loops in JS because iterators are yuckie and slow. Then you say every language struggles with huge arrays. Why the fuck even bring that up if you weren't trying to imply anything about the performance of iterators and function calls. Taken at face value, without me reading between the lines, it /literally/ goes against your argument by stating that if your array is large you're fucked anyway, for loop or not. So what's the problem with iterators again?

@12bitfloat @lensflare said “It’s generally a bad sign if you need to worry about performance when using the very basics of a language”. Yes, JS is slower than Rust, big deal.

About long arrays. Longer arrays in Rust take longer time to iterate through than short arrays in Rust. I hope there's no arguing that.

In JS, for vs. forEach is insignificant on short arrays, but can win time on long arrays.

…at least this was my original argument. I read it in an article Addy Osmani's book several years ago. But now because of this fuss I went and tested it, and now it's not the case, and forEach is actually faster than for, at least in Firefox.

@kiki Well, that's kinda surprising. Not that I wanted to argue that filter is faster than a for loop (didn't think it was). I just think that in some functions that aren't called a lot (or in Rust/C++ most functions even if called a lot), iterators are better for readibility and so why not use them

@kiki my point was never about "JS is slower than other languages, therefore pathetic".

My point was about "if JS' fundamental functions are that much slower than the for statement to be considered bad practice for large arrays, than that’s pathetic".

So, after your tests that doesn’t seem to be the case and I’m ok with it to take back that I called JS pathetic, for THIS reason (It’s still pathetic for many other reasons).

It just became very confusing when you started to bring up big-O, because it doesn’t have to do with any of it. And you made it look like we are the idiots here.

Then you started to refer this to your 500.000 code and internet points and what not. Wtf?

@12bitfloat with my latest discovery considered, there are no reasons left to use for loops as iterators in JS.

@Lensflare I apologize for personal attacks.

I also tested filter, just for fun. It has the same perf as forEach.

Are we talking about old school for loops with explicit indices, or the newer for..of?

I think for..of looks nicer than forEach with its nested scope. It's also nicer (and less error prone) than manually working with indices in old school for loops.