> Sure, and one day the JVM will get TCO just as it's getting value types
You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.)
[1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.
The JVM is full of large projects that are only relevant to non-Java languages, like the vast bulk of java.lang.invoke, the Graal/Truffle projects etc. They've seemed serious about non-Java languages for a long time now. However/unfortunately, almost all the work has gone into support for dynamically typed languages like Ruby or JavaScript. Given the relative popularities of dynamic vs FP languages that's not surprising. If FP languages that relied on TCO were far more popular it'd probably have been prioritised already.
You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.)
[1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.