Comment by nkozyra | Hacker News Reader

Comment by nkozyra | Hacker News Reader

Parent Full thread

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.

Further reading for those interested:

http://www.programcreek.com/2011/09/what-is-the-difference-b...

http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than...

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.

Reply on news.ycombinator.com