4 ms·

What "political" reasons? My understanding of the situation is that it's entirely technical issues that came up after implementing.

runarberg 3y ago
I think the most cited reason they give is diminished developer experience. That is when developers write a recursive function without intending it to be tail call optimized, they loose their call stack. In theory this makes debugging harder. However I don’t—and others interested in JavaScript design—don’t buy this reasoning. There is little—if any—data showing this happens to developers in real life. I also believe that Google’s representatives at TC-39 (and Mozilla’s to a lesser extent) knows this. Meaning they have other reasons for not implementing TCO. My personal theory is that they are very much against expending the functional paradigm in JavaScript. TC-39 has been very hostile towards any proposals which would expand the functional paradigm in JavaScript. The decision to advance the hack style pipeline operator (which uses a placeholder) over the F# (functional/tacit) operator is a prime example of this. This, I believe, is purely political.
- odyssey7 3y ago
  Sadly I sense something amuck against the functional paradigm as well. Paul Graham wrote back in 2001 that Lisp was a secret weapon for building a startup due to the developer productivity gains. https://paulgraham.com/avg.html https://paulgraham.com/avg.html As a corollary, the more lisp-like JavaScript is, the more it reduces barriers to entry for launching a tech company, promoting more software engineers into potential new competitors. Could it be that Java and Python are taught in universities because some members of the industry prefer making it more cumbersome for new grads to launch a company? Having significant barriers to entry is business strategy 101.
  - jart 3y ago
    Are you saying that knowing LISP makes you like an instant Paul Graham? If only.
    - odyssey7 3y ago
      Nice try
    - klyrs 3y ago
      Ew, I hope not. I know lisp, I do not want to be Paul Graham.
- sroussey 3y ago
  Having worked on debuggers in JS land I can tell you that it would generate lots of bug reports. Does the developer expect a call stack? Does the developer NOT expect a call stack? Maybe they want to see if the optimization was activated. Bug reports either way. That said, all sorts of weird changes happen when a debugger is enabled. The jit will eliminate various pieces of code and remove variables from scopes, but you better put them back if the debugger stops! This one I remember in Firebug. Oops! ¯\_(ツ)_/¯
  - hajile 3y ago
    Safari has enabled proper tail calls for 8-9 years now and they haven’t caused issues despite Safari having 20% of the worldwide browser market.
    - runarberg 3y ago
      I guess Safari doesn’t have this large a share of developers, who are the main concern here. But I guess we will truly see if this is an issue as Bun increases in popularity.
      - hajile 3y ago
        The major Google "objection" was automated trace loggers. When something goes wrong, they grab the stack trace and ship it off to the developers. In this particular case, devs definitely see the Safari traces when bugs pop up.
        sroussey 3y ago
        I feel like it could be represented in the trace or the debugger or both and eliminate everyone issues. Devs definitely don’t like surprises, but also absolutely hate their tools not telling the truth.
magicalist 3y ago
Yes, what's really important here is that TCO was added to the spec before the modern TC39 process was adopted. Had implementation and usage experience been required before it shipped in the spec, this conversation would have been concluded 9 years ago.
hajile 3y ago
There were no technical arguments from Google. They implemented tail calls and performance was fine. Furthermore, wasm required them to add the functionality back to the jit. MS complained that windows APIs made it slow, but first, they should fix their OS. Second, chrome didn’t have those same issues on windows. Third, they now use chrome, so it’s no longer an objection. Firefox complained that it was work, but they’re also doing it for wasm. This only leaves the stack trace argument, but the biggest cases for tail calls are where you’d already be forced to a loop and nobody complains that loops don’t have stack traces. Further, you already have the same issues with async stack traces and activating shadow stacks in debug mode works just as well as those async traces. It’s all about chrome devs digging in their heels because they took a side dumb argument and won’t just swallow their pride and implement what developers want and the spec demands.
- Rapzid 3y ago
  > Firefox complained that it was work LOL, as they do.
- chrismorgan 3y ago
  Anything to do with tail calls in WASM is likely to be completely irrelevant to proper tail calls in ECMAScript: they’ll be separate pieces of code with different reasons and balances. Moreover, tail call elimination is explicit in WASM. The initially-defined call and call_indirect instructions aren’t allowed to do tail call elimination, and the tail-call proposal added return_call or return_call_indirect which require it. The situation is thus more like the (now inactive) TC39 Syntactic Tail Calls proposal. No need to worry about the debugging or performance implications. > Firefox complained that it was work, but they’re also doing it for wasm. They said it was impossible to implement across realms with their membrane-based security model. That is: “we could do it in most cases, but you’ve said we have to do it in all cases and we can’t do that without replacing a fundamental and pervasive part of our engine, which we certainly don’t want to do for something we and others aren’t convinced is even a good idea”. But in WASM, any tail calls are to the same WASM program, where this isn’t a problem.
  - hajile 3y ago

runarberg 3y ago

I think the most cited reason they give is diminished developer experience. That is when developers write a recursive function without intending it to be tail call optimized, they loose their call stack. In theory this makes debugging harder. However I don’t—and others interested in JavaScript design—don’t buy this reasoning. There is little—if any—data showing this happens to developers in real life. I also believe that Google’s representatives at TC-39 (and Mozilla’s to a lesser extent) knows this. Meaning they have other reasons for not implementing TCO. My personal theory is that they are very much against expending the functional paradigm in JavaScript. TC-39 has been very hostile towards any proposals which would expand the functional paradigm in JavaScript. The decision to advance the hack style pipeline operator (which uses a placeholder) over the F# (functional/tacit) operator is a prime example of this. This, I believe, is purely political.

odyssey7 3y ago
Sadly I sense something amuck against the functional paradigm as well. Paul Graham wrote back in 2001 that Lisp was a secret weapon for building a startup due to the developer productivity gains. https://paulgraham.com/avg.html https://paulgraham.com/avg.html As a corollary, the more lisp-like JavaScript is, the more it reduces barriers to entry for launching a tech company, promoting more software engineers into potential new competitors. Could it be that Java and Python are taught in universities because some members of the industry prefer making it more cumbersome for new grads to launch a company? Having significant barriers to entry is business strategy 101.
- jart 3y ago
  Are you saying that knowing LISP makes you like an instant Paul Graham? If only.
  - odyssey7 3y ago
    Nice try
  - klyrs 3y ago
    Ew, I hope not. I know lisp, I do not want to be Paul Graham.
sroussey 3y ago
Having worked on debuggers in JS land I can tell you that it would generate lots of bug reports. Does the developer expect a call stack? Does the developer NOT expect a call stack? Maybe they want to see if the optimization was activated. Bug reports either way. That said, all sorts of weird changes happen when a debugger is enabled. The jit will eliminate various pieces of code and remove variables from scopes, but you better put them back if the debugger stops! This one I remember in Firebug. Oops! ¯\_(ツ)_/¯
- hajile 3y ago
  Safari has enabled proper tail calls for 8-9 years now and they haven’t caused issues despite Safari having 20% of the worldwide browser market.
  - runarberg 3y ago
    I guess Safari doesn’t have this large a share of developers, who are the main concern here. But I guess we will truly see if this is an issue as Bun increases in popularity.
    - hajile 3y ago
      The major Google "objection" was automated trace loggers. When something goes wrong, they grab the stack trace and ship it off to the developers. In this particular case, devs definitely see the Safari traces when bugs pop up.
      - sroussey 3y ago
        I feel like it could be represented in the trace or the debugger or both and eliminate everyone issues. Devs definitely don’t like surprises, but also absolutely hate their tools not telling the truth.

magicalist 3y ago

Yes, what's really important here is that TCO was added to the spec before the modern TC39 process was adopted. Had implementation and usage experience been required before it shipped in the spec, this conversation would have been concluded 9 years ago.

hajile 3y ago

There were no technical arguments from Google. They implemented tail calls and performance was fine. Furthermore, wasm required them to add the functionality back to the jit. MS complained that windows APIs made it slow, but first, they should fix their OS. Second, chrome didn’t have those same issues on windows. Third, they now use chrome, so it’s no longer an objection. Firefox complained that it was work, but they’re also doing it for wasm. This only leaves the stack trace argument, but the biggest cases for tail calls are where you’d already be forced to a loop and nobody complains that loops don’t have stack traces. Further, you already have the same issues with async stack traces and activating shadow stacks in debug mode works just as well as those async traces. It’s all about chrome devs digging in their heels because they took a side dumb argument and won’t just swallow their pride and implement what developers want and the spec demands.

Rapzid 3y ago
> Firefox complained that it was work LOL, as they do.
chrismorgan 3y ago
Anything to do with tail calls in WASM is likely to be completely irrelevant to proper tail calls in ECMAScript: they’ll be separate pieces of code with different reasons and balances. Moreover, tail call elimination is explicit in WASM. The initially-defined call and call_indirect instructions aren’t allowed to do tail call elimination, and the tail-call proposal added return_call or return_call_indirect which require it. The situation is thus more like the (now inactive) TC39 Syntactic Tail Calls proposal. No need to worry about the debugging or performance implications. > Firefox complained that it was work, but they’re also doing it for wasm. They said it was impossible to implement across realms with their membrane-based security model. That is: “we could do it in most cases, but you’ve said we have to do it in all cases and we can’t do that without replacing a fundamental and pervasive part of our engine, which we certainly don’t want to do for something we and others aren’t convinced is even a good idea”. But in WASM, any tail calls are to the same WASM program, where this isn’t a problem.
- hajile 3y ago