![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/c0ed0a36-2496-4b4d-ac77-7d2fd7f2b5b7.png)
Please no, don’t subsidize anything Java-Script. It will only make it less efficient.
Please no, don’t subsidize anything Java-Script. It will only make it less efficient.
Interesting.
So it basically enables some more compiler magic. As an embedded guy I’ll stay away from it, since I like my code being translated a bit more directly, but maybe I’ll look into the generated code and see if I can apply some of the ideas for optimizations in the future.
I never looked into this, so I have some questions.
Isn’t the overhead of a new function every time going to slow it down? Like I know that LLVM has special instructions for Haskell-functions to reduce overhead, but there is still more overhead than with a branch, right? And if you don’t use Haskell, the overhead is pretty extensive, pushing all registers on the stack, calling new function, push buffer-overflow protection and eventual return and pop everything again. Plus all the other stuff (kinda language dependent).
I don’t understand what advantage is here, except for stuff where recursive makes sense due to being more dynamic.
Can we stop pretending Rust doesn’t take performance trade-offs? Of course if you compare it one to one its roughly the same, since it’s compiled. But Optimizing memory for cache hits becomes a lot more difficult in Rust, to the point where you have to use unsafe. And unsafe Rust has more undefined behavior than C. In my opinion C is more safe than unsafe Rust.
If you want normal performance its a good Language, but once you need to Optimize memory, which is usually the bottleneck, You are out of luck.
NOOOOOOOO