The Go solution is incorrect. It's not using int64, and most of the finishes are bigger than a 32bit int.
If you run it on the following input:
"""
2
8 10000200002
1 500
"""
You will see that the loop that runs from start to finish is not running on the first case, because it sees the finish as 0.
Haven't tested it using int64, but I would imagine it would be much slower(Still a decent bit faster than Ruby presumably), because any heavy computation for this problem was removed.
I noticed that as well [1], and rewriting the code to use int64 (and thus cover the entire range) makes the Go code run in 2m40s. Still faster than Ruby, but not as incredible as the author thought it was.
