> Otherwise you'd have to explicitly code a loop where you would much rather use recursion.

I find it much easier to reason about loops than to reason about recursion. Likewise I find it much easier to write loops than to write recursive functions.

It probably comes down to experience mainly. I spent some time with functional languages, but I have spent far far far more time writing imperative procedural code.

Even a simple problem such as the 'Towers of Hanoi' looks to me like a pretty messy solution when done with loops and with recursion it all just falls into place.

Recursion is great due to the implicit stack. The cases where you don't have an implicit stack, ie where tail call optimization works, are usually easier and much clearer to just do in a loop.

> Otherwise you'd have to explicitly code a loop where you would much rather use recursion.

The language would have to change for you to be able to code a loop. And that would have all sorts of consequences: in Erlang, preemption happens at function calls and no loops means a bounded time until you make a function call or terminate, with loops, that changes and preemption gets more difficult.

> in Erlang, preemption happens at function calls

I didn't think this was true. The secret sauce was that Erlang preempted on reduction counts, so as a result nothing has any responsibility to yield itself.

edit: ah, literally no difference between the two in the implementation.

That's mostly an implementation detail though, the thread switch could happen just about anywhere. Function calls are a convenient stopping point but the way the reductions are implemented in Erlang it could theoretically be done on any boundary.

It's an implementation detail, but it's very convenient and simplifying, like a lot of Erlang implementation details.

If you take out enough simplifying implementation details, you no longer have a powerful system built from simple parts.

In this particular case though I don't think it would matter much. I've looked pretty closely at how the BEAM does it's thing and it's a work of art, this particular trade-off is more one of convenience than of necessity. But you are right that Erlang is full of such clever (and beautiful) tricks which make it a very interesting codebase to study.

Clojure doesn't have TCO.

Instead, there's loop/recur where the recur call won't compile except in tail position.