I work on Bun - happy to answer any questions
Hi! I saw your PR review of a community effort to add Bun to the Techempower benchmark. You had really great, exact feedback about "unnecessary allocation here", "unnecessary allocation there".
It was eye-opening, in terms of how often us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations.
Given that context, I'm curious:
1) How much you think Bun's (super-appreciated!) fanatical OCD about optimizing everything "up to & outside of JSC" will translate to the post-boot performance of everyday backend apps, and
2) If you're tempted/could be compelled :-D to create a "Mojo of TypeScript", where you do a collab with Anders Hejlsberg to create some sort of "TypeScript-ish" language that, if a TS programmer plays by a stricter set of rules + relies on the latest borrowing inference magic, we could bring some of the Bun amazing-performance ethos to the current idiomatic FP/JS/TS style that is "lol allocations everywhere". :-)
Or, maybe with Bun bringing the right native/HTTP/etc libraries wrapped around the core runtime, doing "just the business logic" in JS really won't be that bad? Which iirc was the theory/assertion of just-js when its author was benchmark hacking Techempower, and got pretty far with that approach.
Anyway, thanks for Bun! We're not running on it yet, but it's on the todo list. :-)
> us JS programmers play fast & loose with "a little filter" here, "a little map" there, and end up with death by a thousand allocations.
That's because speed isn't always top priority. Readability is very high on the list.
I would rather have a slightly slower .map or .filter in a chain than a harder to read nested for or while loop.
The real problem here with the spec committee.
Lodash is MUCH faster than native because it uses iterators so you aren't actually looping over and over.
We need builtin iterator versions of all these looped functions so it adds an implicit/explicit `.valueOf()` that calls the chain and allocates only one new array.
But it's not going to help all that much with this problem. The iterator protocol in JS involves an allocation for every individual value, and while in some cases that can be optimized out, it's pretty tricky to completely optimize.
It's always going to be difficult to beat a c-style for loop for performance.