4 ms·
It's easy in functional languages where execution order and side effects aren't an issue. In JS with prototype monkey-patching you can't even know that the call
by pornel 6y ago
It's easy in functional languages where execution order and side effects aren't an issue. In JS with prototype monkey-patching you can't even know that the call to `.map()`, or anything that it touches, won't suddenly replace the implementation of the `.filter()` method that follows it.
The large amount of IR given to LLVM is closely related to the amount of abstractions that Rust uses. It's especially relevant for iterators where a "simple" `for` loop expands to `into_iter()`, `iter.next()`, `match`, `drop`, and arithmetic expands to calls to overloadable operator methods, all moves are `memcpy` to clean up, and so on.
https://rust.godbolt.org/z/71aEnf9Ta https://rust.godbolt.org/z/71aEnf9Ta
- pjmlp 6y agoI remember the days when functional languages wasn't a synonym for like Haskell does it. Speaking of which just use OCaml bytecode backend or Haskell interpreter to see how slow complex languages are. This is what is missing to Rust and cranelift might help to deliver, alongside not having to keep compiling the whole world from scratch.
- 8fGTBjZxBcHq 6y agoI don't know about JS's particular challenges here and I believe you but a lot of languages with a lot of other features also do this optimization. It's not just the hardcore functional ones though admittedly maybe mostly in the ones most influenced by them.