5 ms·

Still disappointed that Node has backed out of optimized tailcalls (edit: should have written proper tail calls here, since that's what the past 3 now specs hav

Still disappointed that Node has backed out of optimized tailcalls (edit: should have written proper tail calls here, since that's what the past 3 now specs have called for, ES5, ES6, and ES2017). I think it's the only part they haven't implemented. I think a lot of the pushback I'm seeing against TCO comes from traditional programmers who don't like functional programming and who think that recursion shouldn't play any role in production software. I get that there are also some who have legitimate implementation concerns, but the reflexive pushback TCO gets from a lot of the V8 maintainers compared to any other new ES6 feature seems telling to me (correct me if I'm wrong here). What they don't understand is that JavaScript programmers are rapidly moving toward functional programming. Already, there's a heavy functional influence on the React community, probably the dominant frontend framework/library at the moment. Clojurescript and Elm have had an outsize influence on the JavaScript community, and I see more and more programmers using functional paradigms in their everyday code (particularly maps, filters, and reductions). I know we'd see much more recursion if it were technically feasible. Edit: Absolutely right, my critics. I brain farted on this one. It's not Node, it's V8. I did refer to this in the second paragraph, but stupidly blamed Node for it in the first paragraph. Edit 2: As I said, I shouldn't have singled out Node, particularly since it's V8 that's making this call. But my criticism was more directed toward most of the JavaScript implementers who seemed to have single-handedly decided that the es6 spec was all cool except for the one part they don't like. And I could accept the criticism that implicit tailcalls are problematic, except they seem opposed to labeled tailcalls as well. I think there are lots of implementers who simply don't believe that recursion has a place in "real" software. I've not heard these exact words from an implementers before, but I've known quite a few senior developers of my generation (40s) who have said this exact thing to me (they also can't seem to get the difference between structural and generative recursion).

koolba 9y ago
Does V8 handle them? If not how would we expect Node to do so?
- jnbiche 9y ago
  You're correct, I updated my post accordingly.
coldtea 9y ago
>Still disappointed that Node has backed out of optimized tailcalls, which is part of the ES6 spec. I think it's the only part they haven't implemented. Node doesn't implement JS features. V8 does and Node gets updated to newer V8 releases every while. Node doesn't have much say in whats gets to v8. >I think a lot of the pushback I'm seeing against TCO comes from traditional programmers who don't like functional programming and who think that recursion shouldn't play any role in production software. I get that there are also some who have legitimate implementation concerns, but the reflexive pushback TCO gets from a lot of the V8 maintainers compared to any other new ES6 feature seems telling to me (correct me if I'm wrong here). You're overthinking this. There is no masterplan and no pushback. Just some issues with the old standard -- v8 has even implemented the feature in initial form (but not enabled): https://v8project.blogspot.gr/2016/04/es6-es7-and-beyond.html https://v8project.blogspot.gr/2016/04/es6-es7-and-beyond.htm...
- jnbiche 9y ago
  > There is no masterplan and no pushback. I don't think there's a masterplan or some anti-functional conspiracy, but I do think there's pushback. They implemented the feature behind a flag but from what I've read (can't find the reference now), they are not planning to ever release it.
  - coldtea 9y ago
    Probably looking for this then: https://github.com/tc39/proposal-ptc-syntax/issues/22 https://github.com/tc39/proposal-ptc-syntax/issues/22 But their pushback is for pragmatic reasons, not because they don't like recursion/tail calls.
    - jnbiche 9y ago
      > But their pushback is for pragmatic reasons I saw zero reasons given for the failure to implement in that thread (which I had not seen before), other than a brief mention of stack traces (which is quite solvable with a shadow stack). All I saw were several people (including someone involved with the spec) who were bitterly disappointed about the failure to implement. And I forgot that tail call elimination was introduced back in ES5, and yet only JavaScriptCore has implemented it. Which again leads me to believe that most implementers believe it's just not worth the trouble to them to implement a key feature for functional programming, regardless of how much the users want it (the feedback in this thread is similar to what i've seen elsewhere).
ilkkao 9y ago
all engines except Safari's JavaScriptCore seem to have decided that implicit tailcalls optimization wasn't a good idea after all and as far I can see are not planning to enable it.
- jnbiche 9y ago
  Yeah, they say that, and yet they don't want explicit tailcalls either.
  - hashseed 9y ago
    iirc JSC folks are blocking explicit tailcalls on TC39
    - jnbiche 9y ago
      Well, not surprised, because they actually did the work and implemented the spec calling for implicit tailcalls, and then it turned out that the other JS engines were to lazy or biased to implement it themselves (mind, all the other parts of the spec were fine, but the one thing they disagreed with they just didn't implement). So yeah, I'm sure I'd be pretty pissed if I were the JSC devs, and not so happy about the community turning around and saying now we want explicit tailcalls. And by the way, they're also probably smart enough to see that the V8, SM, and ChakraCore are probably not really going to follow through with explicit tailcalls anymore than they would with implicit ones. Being explicit won't make the implementation any easier, it will just firewall off any performance issues (note that JSC achieved this with implict tailcalls). And since the other engines having been complaining against how hard tailcalls would be to implement, it's unlikely they'll do it regardless of whether they're implicit or explicit.
specialist 9y ago
Huh. No tailcall optimization? Then I don't understand something and have to recheck. I just wrote a Redis REPL (wire protocol) parser using recursion. Being so simple, I wasn't worried about stack depth. But while stepping thru with WebStorm's debugger, I noticed the tailcalls were (apparently) being eliminated. An unexpected surprise. Using nodejs 6.11.1, npm 3.10.10.
- dvlsg 9y ago
  Yeah, tail call optimization has been in since node 6, I believe. _Maybe_ behind a v8 flag. https://bugs.chromium.org/p/v8/issues/detail?id=4698 https://bugs.chromium.org/p/v8/issues/detail?id=4698
- eric_bullington 9y ago
  It's behind a flag now, but they're eliminating it, so it will not be released.

koolba 9y ago

Does V8 handle them? If not how would we expect Node to do so?

jnbiche 9y ago
You're correct, I updated my post accordingly.

coldtea 9y ago

>Still disappointed that Node has backed out of optimized tailcalls, which is part of the ES6 spec. I think it's the only part they haven't implemented. Node doesn't implement JS features. V8 does and Node gets updated to newer V8 releases every while. Node doesn't have much say in whats gets to v8. >I think a lot of the pushback I'm seeing against TCO comes from traditional programmers who don't like functional programming and who think that recursion shouldn't play any role in production software. I get that there are also some who have legitimate implementation concerns, but the reflexive pushback TCO gets from a lot of the V8 maintainers compared to any other new ES6 feature seems telling to me (correct me if I'm wrong here). You're overthinking this. There is no masterplan and no pushback. Just some issues with the old standard -- v8 has even implemented the feature in initial form (but not enabled): https://v8project.blogspot.gr/2016/04/es6-es7-and-beyond.html https://v8project.blogspot.gr/2016/04/es6-es7-and-beyond.htm...

jnbiche 9y ago
> There is no masterplan and no pushback. I don't think there's a masterplan or some anti-functional conspiracy, but I do think there's pushback. They implemented the feature behind a flag but from what I've read (can't find the reference now), they are not planning to ever release it.
- coldtea 9y ago
  Probably looking for this then: https://github.com/tc39/proposal-ptc-syntax/issues/22 https://github.com/tc39/proposal-ptc-syntax/issues/22 But their pushback is for pragmatic reasons, not because they don't like recursion/tail calls.
  - jnbiche 9y ago
    > But their pushback is for pragmatic reasons I saw zero reasons given for the failure to implement in that thread (which I had not seen before), other than a brief mention of stack traces (which is quite solvable with a shadow stack). All I saw were several people (including someone involved with the spec) who were bitterly disappointed about the failure to implement. And I forgot that tail call elimination was introduced back in ES5, and yet only JavaScriptCore has implemented it. Which again leads me to believe that most implementers believe it's just not worth the trouble to them to implement a key feature for functional programming, regardless of how much the users want it (the feedback in this thread is similar to what i've seen elsewhere).

ilkkao 9y ago

all engines except Safari's JavaScriptCore seem to have decided that implicit tailcalls optimization wasn't a good idea after all and as far I can see are not planning to enable it.

jnbiche 9y ago
Yeah, they say that, and yet they don't want explicit tailcalls either.
- hashseed 9y ago
  iirc JSC folks are blocking explicit tailcalls on TC39
  - jnbiche 9y ago
    Well, not surprised, because they actually did the work and implemented the spec calling for implicit tailcalls, and then it turned out that the other JS engines were to lazy or biased to implement it themselves (mind, all the other parts of the spec were fine, but the one thing they disagreed with they just didn't implement). So yeah, I'm sure I'd be pretty pissed if I were the JSC devs, and not so happy about the community turning around and saying now we want explicit tailcalls. And by the way, they're also probably smart enough to see that the V8, SM, and ChakraCore are probably not really going to follow through with explicit tailcalls anymore than they would with implicit ones. Being explicit won't make the implementation any easier, it will just firewall off any performance issues (note that JSC achieved this with implict tailcalls). And since the other engines having been complaining against how hard tailcalls would be to implement, it's unlikely they'll do it regardless of whether they're implicit or explicit.

specialist 9y ago

Huh. No tailcall optimization? Then I don't understand something and have to recheck. I just wrote a Redis REPL (wire protocol) parser using recursion. Being so simple, I wasn't worried about stack depth. But while stepping thru with WebStorm's debugger, I noticed the tailcalls were (apparently) being eliminated. An unexpected surprise. Using nodejs 6.11.1, npm 3.10.10.

dvlsg 9y ago
Yeah, tail call optimization has been in since node 6, I believe. _Maybe_ behind a v8 flag. https://bugs.chromium.org/p/v8/issues/detail?id=4698 https://bugs.chromium.org/p/v8/issues/detail?id=4698
eric_bullington 9y ago
It's behind a flag now, but they're eliminating it, so it will not be released.