Yes, there were some discussions about explicit tail call optimizations being the better solution.

Interesting, why would adding an optimize this keyword to JavaScript be better?

I don’t know their motivations, but having the same code work fine on one JS engine / browser / browser version, but totally stack overflow on another seems like suboptimal to me. Explicit tail calls let you error out properly at the call site, Babel-style downcompile it to a loop of some sort, all that stuff.

This could be surprising, but the scenario already exists in production. In JavaScript's strict mode, Safari applies tail call optimization, but systems relying on V8 don't.

To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari.

  "use strict";
  const countdown = (n) => n == 0 ? console.log('done') : countdown(n-1);
  countdown(100000);

the same discussion is going on with rust. it lets the compiler enforce that you're actually using a tail call, instead of silently optimizing it when it sees it and otherwise being silent.

Generally the people that care about tail calls write code that relies on them. It isn't just an optimisation. The code is broken (will cause a stack overflow) if TCO isn't applied. So you need to guarantee it.

If I try to trace through the risk profile of bringing TCO into software engineers’ toolkits, it seems that the fear would be of the software engineers growing recursion-happy and writing functions that overflow the stack by inadvertently not leveraging TCO, more than they write recursive functions today that overflow the stack given that V8 offers no possibility of TCO at all? It just doesn’t add up, V8 with TCO and no safety keyword would simply be better than V8 today with neither, so it would still be a strange basis for not delivering the feature.

I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.

It adds up to me. It only takes being bitten once to learn that tail calls aren't optimized, and then you stop using them for recursion (or almost entirely stop). You write a for loop and things work. The overall level of broken code is very low.

If it's inconsistent, then people write a lot more tail calls and a lot more sites break on a lot more devices.

This is the description of a workaround for dealing with tail recursion being broken in V8.

It doesn’t add up if V8 is withholding TCO under the guise that it would cause programmers to write stack overflow bugs unless a new proposed keyword for it gets added to the language. The truth currently is that V8 itself has a stack overflow bug in its omission of TCO, it wouldn’t be right to shift the responsibility for that to the JavaScript programmers. But you’re right, unfortunately the JavaScript programmers are the ones who have to deal with the consequences of V8’s spec non-compliance which causes the stack to overflow when it shouldn’t.

I quite like that Clojure’s recur makes it easy to tell at a glance if a recursion will be efficient.