Recursion and Tail call optimization

Hi there,

I’m a huge fan of recursion in general and few weeks ago I found that blog post(http://www.goinggo.net/2013/09/recursion-and-tail-calls-in-go_26.html) on how go is not optimized for recursion and I got really disappointed.

That article is about a year old, so I’m hoping tail call optimization is coming up or have already been implemented. Does anyone have more information on that?

Would be great to have a community push around it, it would improve code quality IMHO!

There are no plans to implement tail call recursion in Go.

@dfc no plan in like no current plan or no plan ever? If so I’d be curious to know the reason behind that – if you know them.

Thanks,
Thomas

rsc views tail call recursion as an extreme form of inlining and his general concerns about inlining messing up stack traces applies.

rsc commented on Nov 5
We’re not going to eliminate tail calls. Let’s just get that out of the way.

Source: runtime: FuncForPC/FileLine/Caller/Callers api interferes with implementation of better inlining · Issue #11432 · golang/go · GitHub

Ah Thanks for the context guys. So I guess the answer for recursion in go is Don’t use it.

That’s entirely untrue, recursion is still a reasonable answer for many problems that can not be solved differently.
if the problem can be solved using a loop however, that’s indeed the recommended way in Go

You should absolutely use recursion in Go, that’s what growable stacks are designed for.

1 Like

Right but as Luna mentioned it won’t be as efficient as using a loop (assuming you can write it with a loop) or is that a wrong statement? Also I guess there’s a risk of growing the stack too much isn’t it?

Depends, whenever you mention performance, I’m duty bound to ask you to profile your code.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.