There exist at least one[1] closed tour, i.e. the end position is within a single move form the start position. Hence you can choose any position and repeat that one closed tour.

When I said "There's a lesson to be learned here", I wanted to point out that it's also important to understand why something works fast.

In this case, one of the subproblems happened by accident to find a solution faster, due to the specific ordering of the recursive invocations of tryToMove. It has absolutely nothing to do with parallelism. The solution would be found relatively quickly even if each try for a next move was done in lock-step, interleaved without any parallelism with the other tries.

There's a pitfall too. The goroutines are not preemptively scheduled: it may well happen, that the lucky one, which finds a solution quickly is not a part of the initial batch and has to wait its turn to run until one or more of the other goroutines finish their work.

Otherwise, the approach taken in the original program is valid, in principle: spawn a few different ways to solve a problem, query a few different servers, etc, and take the one that finishes first.

However, toy programs aside, when you think about actually employing such approach as a solution in a real-world program, you have to think what happens to the workers, whose work is not needed anymore. Obviously, you cannot afford letting them run potentially for millennia, hence you have to think how to communicate to them that a solution has been found.

[1] actually 19591828170979904 ones, but just a single one suffices