It depends on how you're defining defining "decentralised application", and what you consider the differences to be between a Dapp and a smart contract, where they sit in the overall architecture, and how the terms relate to each other.
From what I can remember from looking a while ago at the book you reference, it's not using Go as a smart contracting language (at least I don't think it is... ), which is what Solidity is.
Links that might be useful reading:
I'm confused as to how this might be compiled and distributed to the
EVMs on the network
There's currently no way to write smart contracts in Go, and have them compile to EVM bytecode. You'd have to write the compiler to do that. Why this would be a bad idea, specifically for Go, has been covered in the past.
See: What is the merit of creating new smart contract languages like Solidity instead of using other languages?
From the guy who writes most of the Geth code...:
"A while ago I've spent quite a lot of time to create a Go -> EVM cross compiler. I did manage to run a few trivial programs and it definitely was a lot of fun, but quite soon I've started to hit the limitations of the EVM that clashes with the core assumptions behind Go..."
And also - what are the differences between Golang and Solidity in
terms of writing decentralized applications?
Solidity is smart contract language, Go, as above, isn't, and probably never will be, at least in Ethereum. Go could be used for other parts of your Dapp, i.e. parts of the front-end, or parts of the back-end that isn't the blockchain.