3 ms·

Not hard at all. Chrome had it implemented, removed it, then added it back, but only for WASM. They disliked that it didn't leave stack frames in some cases.

by hajile 3y ago

Not hard at all. Chrome had it implemented, removed it, then added it back, but only for WASM. They disliked that it didn't leave stack frames in some cases. Apple refused to break the JS backward-compatibility guarantee and implemented as-per the spec and Chrome refused to turn on their implementation for users unless it added a special keyword to identify it as a tail call. Chrome dev's emotional investment and resulting stubbornness has split the JS community and made their implementation incompatible with the spec. They are 100% in the wrong here.

baq 3y ago
In the meantime on the backend we’re looking at stack traces cut apart with trampolines and living with it…
robocat 3y ago
> Chrome dev's emotional investment and resulting stubbornness ... You really undermine your position when you start fabricating bullshit like that. The chromium team had good reasons to not implement it (including clusterfuzz security issues). Apparently it was actually the Microsoft and Mozilla teams that blocked the feature: https://stackoverflow.com/questions/54719548/tail-call-optimization-implementation-in-javascript-engines#54721813 https://stackoverflow.com/questions/54719548/tail-call-optim...
- hajile 3y ago
  FF objected because they didn't want to do the work, but they're now doing that work making proper tail calls work in WASM, so their objection is irrelevant now. MS objected that Windows APIs made PTC slow, but they now use Chrome, so they don't have an excuse today either. There's nothing inherently insecure about proper tail calls and that is pure FUD. That just leaves Google. They chose to die on the hill of syntactic tail calls and are still refusing to implement the spec. The only reason left is their pride and emotional investment in STC. Even back then, Safari was implementing and had more marketshare than Edge and FF combined (now 2.5x their combined market share with FF only having around 3% share today). I'm tired of bad excuses and want them to actually implement the now 8 year old spec properly.

by hajile 3y ago

baq 3y ago

In the meantime on the backend we’re looking at stack traces cut apart with trampolines and living with it…

robocat 3y ago

> Chrome dev's emotional investment and resulting stubbornness ... You really undermine your position when you start fabricating bullshit like that. The chromium team had good reasons to not implement it (including clusterfuzz security issues). Apparently it was actually the Microsoft and Mozilla teams that blocked the feature: https://stackoverflow.com/questions/54719548/tail-call-optimization-implementation-in-javascript-engines#54721813 https://stackoverflow.com/questions/54719548/tail-call-optim...

hajile 3y ago
FF objected because they didn't want to do the work, but they're now doing that work making proper tail calls work in WASM, so their objection is irrelevant now. MS objected that Windows APIs made PTC slow, but they now use Chrome, so they don't have an excuse today either. There's nothing inherently insecure about proper tail calls and that is pure FUD. That just leaves Google. They chose to die on the hill of syntactic tail calls and are still refusing to implement the spec. The only reason left is their pride and emotional investment in STC. Even back then, Safari was implementing and had more marketshare than Edge and FF combined (now 2.5x their combined market share with FF only having around 3% share today). I'm tired of bad excuses and want them to actually implement the now 8 year old spec properly.