At my job, before I joined, I was told we were torn between using Go and Rails and ended up with both. Now we have a Rails frontend (for web requests / authentication) and a Go backend (for business logic), which communicate over Thrift RPC.

I don't think it was a very wise decision because not only are you doing things twice, you're doing it three times, because you have to serialize/deserialize to/from Thrift for every request. It adds development time, more tests, and Thrift's binary protocol makes debugging RPC almost impossible.

This isn't really an argument for/against Go, but it just shows that you should try to avoid using multiple codebases that have to be tightly integrated. Personally, I would've gone with a Ruby-only codebase that used Thrift RPC only if there was some backend task that was too slow in Ruby, and that Go's concurrency and speed might be better at. Then I'd serialize it and send it over to be processed by a better language. I wouldn't do it for every request.

That being said, if I had the choice between writing an API in Go vs Rails, I would do it in Rails for the faster iterative development speed and quick debugging capabilities that is made possible by an interpreted language.