Live data from Hacker News

What happened to proper tail calls in JavaScript? (2021)

mgmarlow.com

11–20 of 146 posts

Re: What happened to proper tail calls in JavaScript? (2021)

#11

One advantage of syntactic tail calls is that you can give an error if you are unable to transform to a tail call. Otherwise, you could have a program that seems to work file, and then you refactor and now your recursion isn’t a tail call anymore, and your stack blows up.

Perhaps with a syntax for tail calls, you could do it not at the end of a function.

Re: What happened to proper tail calls in JavaScript? (2021)

#12
post #8

Worth reading why python doesn’t have it either http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

Pretty good arguments in there:

- TCO only addresses recursion that can easily be replaced by a loop

- loosing stack frames makes debugging harder

- its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations

- functional languages with no side effects need recursion, everyone else really doesn't

Personally, I think TCO is bad in a similar way as async functions. It is an exception from the general mental model of how function calls work, makes tooling much more complex and the alternative is just writing a loop, which I know is beneath the average Lambda The Ultimate subscriber, but its just how some people earn their money.

Re: What happened to proper tail calls in JavaScript? (2021)

#13
post #9
post #8

Worth reading why python doesn’t have it either http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

> Python's default is and should always be to be maximally helpful for debugging. I can’t say I understand the whole topic but when someone who knows more than me says that…. It is a pretty compelling argument to me.

I would opt for balance, there is a reason why some languages compile in debug and release mode, because of the tradeoffs.

Having code that is optimal in performance often implies a tradeoff in debuggability. If debugging helpfulness is the major design decision of a programming language, that designer is trading off performance.

Re: What happened to proper tail calls in JavaScript? (2021)

#14
post #9

Earlier quoted context omitted.

> Python's default is and should always be to be maximally helpful for debugging. I can’t say I understand the whole topic but when someone who knows more than me says that…. It is a pretty compelling argument to me.

I would opt for balance, there is a reason why some languages compile in debug and release mode, because of the tradeoffs. Having code that is optimal in performance often implies a tradeoff in debuggability. If debugging helpfulness is the major design decision of a programming language, that designer is trading off performance.

It certainly can be a trade-off. I think that's what they're saying for Python, maximizing helpful debugging > that feature.

Re: What happened to proper tail calls in JavaScript? (2021)

#16
post #4

I had the impression, the ECMAScript spec would only accept proposals "after" they were implemented by the major players. How did PTC sneak into the spec?

from the linked PTC proposal in the article (https://github.com/tc39/proposal-ptc-syntax):

> Unfortunately, the TC39 process at this time did not require heavy implementation involvement and so while many implementers were skeptical, the feature was included and standardized as part of ES6.

Re: What happened to proper tail calls in JavaScript? (2021)

#18
post #10
post #9

Earlier quoted context omitted.

> Python's default is and should always be to be maximally helpful for debugging. I can’t say I understand the whole topic but when someone who knows more than me says that…. It is a pretty compelling argument to me.

It's kind of a weird argument though. How do you expect a for loop to be represented in a stack trace?

The problem that’s hard to get around is this:

https://github.com/elixir-lang/elixir/issues/6357

Tail calls don’t have to be recursive. See also this old thread:

https://news.ycombinator.com/item?id=5376924

Re: What happened to proper tail calls in JavaScript? (2021)

#19
post #8

Worth reading why python doesn’t have it either http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

Pretty good arguments in there: - TCO only addresses recursion that can easily be replaced by a loop - loosing stack frames makes debugging harder - its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations - functional languages with no side effects need recursion, everyone else really doesn't Personally, I think TCO is bad in a similar way as as…

Being able to guarantee tail calls is a useful optimization in far more cases than code replaceable by loops. I’ve used it myself where dispatch targets themselves are dynamic (so can’t be trivially made into a loop) for significant performance gains.

Some other folks who’ve done the same thing (and can post publicly) for code that’s not just “must recurse because loops are for lowly imperative serfs”:

* https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

* http://lua-users.org/lists/lua-l/2011-02/msg00742.html

* https://cantortrading.fi/rust_decimal_str/

Now does JavaScript really need/care about any of this? Probably not.

Post reply on HN