3 ms·

Mozilla abandoned XPCOM partly due to the runtime cost of marshalling between C++ and JavaScript. https://yoric.github.io/post/why-did-mozilla-remove-xul-addon

Mozilla abandoned XPCOM partly due to the runtime cost of marshalling between C++ and JavaScript. https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/ https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... I wonder if the solution is transpiling. If Javascript was transpiled to Rust, there would be less data to copy. You would just have two API surfaces. But you wouldn't have runtime Javascript execution, just the capability of running Javascript code at native performances.

jraph 4y ago
> If Javascript was transpiled to Rust Seems challenging. JavaScript code does not come with lifetime information that the Rust compiler expects to have to get rid of stuff that's not used anymore, while JS has a garbage collector to do this. There's also no borrowing information encoded in JavaScript code. Rust expects the developers to provide this information in their code so it knows who and where what can modify what.
KMag 4y ago
I believe automatically inferring lifetimes in the general case is equivalent to solving the halting problem (for every sub-program, determine if a given reference is stored to the heap before the sub-program terminates), so transipiling JS to Rust would presumably need manual lifetime annotation or else require significant limitations to simplify lifetime analysis.
- kaba0 4y ago
  Rust’s lifetimes can’t express arbitrary lifetimes, only “stack-like” ones. Other kinds are very frequent in managed languages and are only possible to deal with due to the GC.