I tried to post this review on gitbooks.io, but couldn't. So I guess I'll put this up here:
This is a great introduction to building web apps in Go. (I started roughly two months ago, but had this book been around, I'd have been brought up to speed a lot faster).
Here's why: the predominant approach to building web apps in Go is to build on top of standard interfaces (e.g. net/http), and to keep things as simple as possible. Heavy, prescriptive frameworks are frowned upon. This is a great approach, but probably strange to people (like me) who come from prescriptive frameworks like Rails or Django.
Jeremy's guide sticks to Go conventions, while respectfully suggesting lightweight libraries that complement this approach. The guide is never "YOU MUST USE THIS", instead it always introduces the bare-bones approach first, and then tells you "hey, there's a 3rd party library that gives you some useful shortcuts on top of those." And indeed, each of the recommended libraries are idiomatic and easy to understand.
My review is probably biased, though, because I now have some idea now of how to write web apps in Go. But I certainly wished this book had existed when I first started.
I disagree that frameworks are frowned upon in Go, it's just that there aren't a ton that are worthy. People will usually be ok with Martini or Revel or Gorilla if they want something really barebones. None of those are really frowned up.
Where you may see people discouraging a framework is when you ask how to do something very basic and attempt to use a framework to solve it. In those cases, you lose the chance to learn exactly how the underlying processes work natively in Go, and since you're already writing in Go, you might as well do it from scratch. Plus all of your code is very reusable going forward.
But if you know how it works and want something quick and fuss-free for a full application nobody will steer you away from the better frameworks.
Many of the Go core contributors and well known to hold that frameworks present an unhealthy inversion of control compared to libraries. The standard library reflects this, for example as "net/http" is very much a library and works very different from applications using IIS or Apache. Many of the earliest gophers hold this position as well. I have been writing Go professionally since before Go 1.0 and I think saying "frameworks are NOT frowned upon in Go" is very much out of touch with the longest standing members of the Go community. I personally think there are cases for frameworks, but that they are few and far between.
In the case of net/http, I think it really turned out that simply integrating with http.Handler has so many more benefits than wrapping net/http with your own interfaces. Even Jeremy Saenz realized that and released Negroni after developing Martini.
I don't know that the parent meant all frameworks are frowned on, but more the "Heavy, prescriptive frameworks ... like Rails or Django."
I say if that's actually the case in the Go community, but I can understand getting that feeling starting out. I'm just starting with Go myself, and I had the same thought after some casual research digging through various blogs, tutorials and library suggestions.
As a newcomer to the language, it seems that there's a drive toward things being very explicit, using very little "magic", and composing smaller libraries, rather than using monolithic frameworks; all of that appeals to me.
If I'm way off base on that, I'd be happy to hear where my understanding is underdeveloped. Like I said, this is just what I get at first blush.
All in all, I'm really interested in checking out the book, and learning more about Go.
> it's just that there aren't a ton that are worthy.
It's just that writing a good web framework is actually way more complex than just a router.Martini,Revel or Gorilla are not webframeworks.
I believe Go is too rigid to allow something like Rails or Django. Go is for people who want C like performances with memory safety and easy concurrency. Go is not a "typesafe" python, at least it doesnt work like one until now. But I wouldnt be surprised someone comes up with a language built on top of Go that looks like a "typesafe" python or a Go++. That's what happens when people dont get their "nice things".
It's not like you need to ask a language community's permission to build your own thing in that language. Before Rails the Ruby community was very OO focused. Rails isn't very OO to be honest. It tends to used lots of composition and duck typing. You can see the major shift in the libraries before and after rails.
The question is, could somebody build a strong framework for web applications on Go? Maybe, i'm still learning the language myself so i don't know. Just because the language designers don't like it, doesn't mean that somebody won't come along and do it.
> always introduces the bare-bones approach first, and then tells you "hey, there's a 3rd party library that gives you some useful shortcuts on top of those."
We need something similar for Clojure web apps, since they both favor libraries over frameworks.
This seems to be the approach most new languages use. People in the Clojure community also emphasize using libraries over frameworks. I think the reason is is that earlier adopters tend to prefer this approach and there is a lot of agreement and development work required to make a full fledged framework like django.
I feel you on this, also coming from Django background, there is no equivalent yet for golang, though I've been skimming with revel for some time, it's still incomplete from what I want. This is just perfect opportunity to learn something that is more disconnected, but syncs with harmony. :)
This is a great introduction to building web apps in Go. (I started roughly two months ago, but had this book been around, I'd have been brought up to speed a lot faster).
Here's why: the predominant approach to building web apps in Go is to build on top of standard interfaces (e.g. net/http), and to keep things as simple as possible. Heavy, prescriptive frameworks are frowned upon. This is a great approach, but probably strange to people (like me) who come from prescriptive frameworks like Rails or Django.
Jeremy's guide sticks to Go conventions, while respectfully suggesting lightweight libraries that complement this approach. The guide is never "YOU MUST USE THIS", instead it always introduces the bare-bones approach first, and then tells you "hey, there's a 3rd party library that gives you some useful shortcuts on top of those." And indeed, each of the recommended libraries are idiomatic and easy to understand.
My review is probably biased, though, because I now have some idea now of how to write web apps in Go. But I certainly wished this book had existed when I first started.