3 ms·
It wouldn't just work for javascript and the way it's used, though. It modifies semantics in a way that would affect the behaviour of existing programs in prod
by kannanvijayan 3y ago
It wouldn't just work for javascript and the way it's used, though. It modifies semantics in a way that would affect the behaviour of existing programs in production environments. It would break things that currently work, and it would break tooling that currently works.
Common tooling for production error tracking (e.g. Sentry) would be greatly affected by such a behavioural change.
Functional languages "just work" with those semantics because those expectations were set up ahead of time, and tooling and developer expectations were molded around them. But JS isn't one of those languages. The tooling and developer expectations, and gargantuan amounts of existing code, has been written with the expectation that calls create stack frames.
> The only FP languages that require explicit syntax, target the JVM, which lacks the support.
Support could be added to the JVM just the same as the JSVM though - via a spec change. And just as with the JSVMs, it would be a semantic change that would alter the behaviour of existing programs in ways that would break existing tooling and make developers lives worse. It's why both of them resist it.
- hajile 3y agoIt might give different tooling output, but the tooling wouldn’t break. Likewise, the only side effect of the code itself is that some of it would get faster because functions wouldn’t need to return. The percentage of sites affected by automated stack tools is far less than the number of other sites that would benefit from tail calls. More importantly, this breakage already happened 8 YEARS ago in Safari and 20% of all web users already break those expectations, so companies should have already adjusted. At this point, it only serves to split the web.