As you probably know (and as you can probably tell from some of the responses here), sometimes choosing languages can be like choosing a religion :-)
As a backend for a web application, Go's performance is pretty great. The Go standard library comes with a fast parallel-enabled HTTP server that already makes use of all your cores in recent Go versions. No need for things like gunicorn to take advantage of cores. There's no interpreter overhead, and there's plenty of benchmark comparisons with other languages out there on Google. I've never heard of someone not using Go as a server-side language because it wasn't fast enough :-)
Go has very robust support for creating web applications. Of course, for the frontend you will still need HTML+CSS+JS (maybe + a JS framework like Angular depending on your needs). There is a crazy experiment called GopherJS to run Go in the browser/frontend, but currently, a crazy experiment is all it is IMO...
For serving dynamic content, the Go standard library comes with its own templating language and library: https://golang.org/pkg/html/template/
The standard library also comes with most of the tools you'll need for defining HTTP routes (see the server examples): https://golang.org/pkg/net/http/
Personally, I've found the following third-party packages to be quite helpful with putting together HTTP server-side apps in Go:
- Gorilla mux for defining templated routes: https://github.com/gorilla/mux
- Negroni for HTTP route Middlewares: https://github.com/codegangsta/negroni
For testing HTTP server-side Go applications, the httptest package is quite helpful:
https://golang.org/pkg/net/http/httptest/As you can see, most of what you need just comes with the standard library, which is quite professionally designed and coded (reading through their source is a pleasure). The two external dependencies I mentioned are helpful, but not a strict requirement to build a server-side app.
The main obstacle people have with using Go IMO has little to do with its ability to be used as a server-side language, and more to do with the nature of the language, and the consequences of its design choices. I think people who strongly prefer terse dynamic languages have trouble adopting/enjoying Go and its way of doing things. For instance, someone in this thread said that Go's structs and static typing makes it harder to work with JSON. You could also make the argument that this is a strength- all I have to do is declare a struct to specify what exactly I want to read from / write to JSON. Some people have complained about Go's verbosity. Sometimes they are right- certain things in Go take a little more text to express. I'm convinced that Go is a language that is more optimized for readability than for writability. You typically can't write "expressive" koans in a line of code... but your teammates probably have a higher chance (in my subjective opinion) of understanding the Go code you wrote a year after you've forgotten what you were thinking about.
I could go on and on, but now I'm just fighting the eternal language holy wars :-)
I hope I've given you a starting point for more research if you were considering Go for a server-side web application.