3 ms·

Maybe because with tail call optimization you wouldn't have a proper stack trace?

by senfiaj 10mo ago

mikehall314 10mo ago
Supposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.
- senfiaj 10mo ago
  Yes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#:~:text=In%20reality%2C%20discarding,the%20debuggability%20issue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
ggggffggggg 10mo ago
I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.
- dataflow 10mo ago
  The difference is loops don't normally have traces but function calls do.
- senfiaj 10mo ago
  I don't know fast it would be if it was done iteratively. But Apple's implementation has negative implications for debuggability: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#:~:text=In%20reality%2C%20discarding,the%20debuggability%20issue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... . V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
  - pygy_ 10mo ago
    That argument was vaguely plausible until WebKit/JavaScriptCore shipped PTC and literally no one bat an eye. Bun users don’t care either. At this point it is pure BS.
    - senfiaj 10mo ago
      > Bun users don’t care either. Most Bun users don't even know about this (unless they are bitten by this). That doesn't mean absolutely no one cares or would not care even though such complaints might be uncommon.

Maybe because with tail call optimization you wouldn't have a proper stack trace?

by senfiaj 10mo ago

Maybe because with tail call optimization you wouldn't have a proper stack trace?

Supposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.

senfiaj 10mo ago
Yes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#:~:text=In%20reality%2C%20discarding,the%20debuggability%20issue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.

ggggffggggg 10mo ago

I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.

dataflow 10mo ago
The difference is loops don't normally have traces but function calls do.
senfiaj 10mo ago
I don't know fast it would be if it was done iteratively. But Apple's implementation has negative implications for debuggability: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#:~:text=In%20reality%2C%20discarding,the%20debuggability%20issue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... . V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
- pygy_ 10mo ago
  That argument was vaguely plausible until WebKit/JavaScriptCore shipped PTC and literally no one bat an eye. Bun users don’t care either. At this point it is pure BS.
  - senfiaj 10mo ago
    > Bun users don’t care either. Most Bun users don't even know about this (unless they are bitten by this). That doesn't mean absolutely no one cares or would not care even though such complaints might be uncommon.