The Go Programming Language is co-authored by Brian Kernighan -- the K in K&R C, the most influential programming book ever written. That is not trivia. It means this book has the same DNA: precise, minimal, every example chosen with surgical care. You will not find filler. You will not find hand-holding. You will find a book that respects your intelligence and expects you to keep up.
Go will frustrate you. I am not sugarcoating this. You are coming from a language where array.select { |x| x > 5 }.map(&:to_s) is one line. In Go, that is a for loop, an if statement, a type conversion, and an append. No blocks. No procs. No method_missing. No monkey patching. You will feel like you are writing assembly with training wheels.
The if err != nil pattern will make you want to throw your laptop. You will write it hundreds of times. You will wonder why a language designed in 2009 does not have exceptions or even a Result type. The answer is that Rob Pike and the Go team believe explicit error handling produces more reliable software than exception-based control flow. They are probably right, but it does not make the typing less tedious.
Here is what will surprise you though: after a few weeks, you will start reading Go code written by strangers and understand it immediately. Every Go developer writes code the same way because there is only one way to write it. There is no "clever" Go. There is no metaprogramming. There is no DSL. The language is so simple that gofmt settles every style debate. After years of Rails, where every team has its own conventions and every gem has its own DSL, this uniformity will feel like relief.
Go will feel like a downgrade from Ruby in expressiveness. It is an upgrade in clarity. That tradeoff is the entire philosophy of the language.