[Ericson2314]

The GC would be shitty, yes. I doubt the runtime itself really cares about tailcails. There could be tiny calling convention issue, you can share the runtime while using a different calling convention, I assume.

People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.

[nu11ptr]

Not sure about now with multicore, but pretty sure OCaml had a "bump" memory allocator previously. These are just a little bit slower than stack allocation as they just involve a pointer increment and is important in functional languages since they allocate a LOT. Go's memory allocator is pretty fast (I played with making a bump allocator for it and it was only 4-5x faster, so very fast), but the slowdown would be noticeable. Also, Go uses a "mark and sweep" style collector (which is the reason it can't use a bump allocator - those require moving on collection, which Go can't do) which just isn't designed for the amount of garbage that FP languages generate. It might work, but it would be quite a bit slower.

[ptman]

Go uses a simple non-generational collector because it avoids generating garbage on the heap by doing escape analysis and allocating on stack. I get the ocaml does a lot of recursion, being functional. But could stack allocation also work for ocaml when using growable stacks?