Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goji: a web microframework for Go

goji.io

Post reply on HN
Print view View original

31–40 of 88 posts

Re: Goji: a web microframework for Go

#31

Post by zenazn »

aalpbalkan wrote: post #27

It is good to have many web microframeworks in a language ecosystem. In Python probably there are a hundred of those. Many of those are not picked up by the community –a natural selection. Only really a few of those survived. It all depends on you if you are going to choose Revel, Martini, Goji or whatever you want. Today, thousands of apps run on web.py, yet most of the source code is untouched last 3-5 years ( http…

Static files: http://golang.org/pkg/net/http/#FileServer

Logging: http://golang.org/pkg/log/

Panic recovery: https://godoc.org/github.com/zenazn/goji/web/middleware#Reco...

Not as many fanboys though (yet!)

Re: Goji: a web microframework for Go

#32

Post by gnaritas »

sagichmal wrote: post #30
gnaritas wrote: post #24

Earlier quoted context omitted.

Yuk, that's just manually doing what ORMs give you automatically; that's not a good thing, you're being a human compiler.

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translation of data and grammar, and as the type relationships grow more complex, ORMs fail. The lesson of ActiveRecord, from the perspective of Go, is that ORMs are fundamentally broken abstractions.

Don't be pedantic, my point was clear and you obviously understood it.

As for the lessons of active record, says who?

Re: Goji: a web microframework for Go

#33

Post by chc »

gnaritas wrote: post #32
sagichmal wrote: post #30

Earlier quoted context omitted.

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translation of data and grammar, and as the type relationships grow more complex, ORMs fail. The lesson of ActiveRecord, from the perspective of Go, is that ORMs are fundamentally broken abstractions.

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

Well, Martin Fowler has gone on the record saying that Active Record (the design pattern, of which Ruby's ActiveRecord is one implementation) is not well-suited to sophisticated data models, and he tends to prefer the Data Mapper pattern — which similar to what's being described for Go.

Re: Goji: a web microframework for Go

#34

Post by _ak »

tptacek wrote: post #8

This is going to sound a little dismissive, but I don't mean it to be: I'm not sure I understand the value that these frameworks offer beyond the HTTP server interface Golang supports out of the box, plus a URL router like "pat" (or whatever the cool kids are using now other than "pat"). I see the clean middleware abstraction, but I find the idiomatic closure-based implementation of middleware adds only a couple extr…

I don't really get it, either.

Generally, what I don't like about web frameworks in Go is that they often don't integrate too well with the existing net/http package. I think we don't need web frameworks, we need web libraries that we can easily plug together as we want without any additional glue.

Re: Goji: a web microframework for Go

#35

Post by kohanz »

sagichmal wrote: post #29
kohanz wrote: post #25

Earlier quoted context omitted.

Thank you for the detailed answer. It's a bit more laborious in the sense of keystrokes, but it's also more explicit, which is, on balance and over the lifetime of a large software project, a good thing. OTOH, it feels like a high development cost to pay, relative to the alternatives out there. You certainly wouldn't use it for an MVP. Also, it would increase the opportunities to introduce bugs into the application (…

> (unless one actually feels they can write something > better than, say ActiveRecord, from scratch). The point is that ActiveRecord's method of modeling, especially when it comes to dynamically mapping language constructs to a storage layer via SQL, is too implicit. Too costly. Actively harmful! The point is to get developers to stop thinking in terms of ORM abstractions, and start thinking in terms of the actual tr…

The point is to get developers to stop thinking in terms of ORM abstractions, and start thinking in terms of the actual transforms and manipulations that are occurring.

Isn't the point also to encourage code re-use and abstraction? I mean, golang has packages for a reason. I suppose my question is more along the lines of whether we'll ever see a package in go that would standardize the data-object divide or whether this will always be a "roll your own" domain?

I think you overestimate the cost of pressing buttons on your keyboard.

Then why don't we "roll your own" for everything?

Re: Goji: a web microframework for Go

#36

Post by Jweb_Guru »

gnaritas wrote: post #32
sagichmal wrote: post #30

Earlier quoted context omitted.

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translation of data and grammar, and as the type relationships grow more complex, ORMs fail. The lesson of ActiveRecord, from the perspective of Go, is that ORMs are fundamentally broken abstractions.

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

I do, for one, but don't take my word for it... lots of very intelligent people have problems with ORMs. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute... presents a good summary of the problems involved (forgive the inflammatory title).

Despite its many problems, SQL remains the best way of interacting with a relational database.

Re: Goji: a web microframework for Go

#37

Post by camus2 »

chc wrote: post #33
gnaritas wrote: post #32

Earlier quoted context omitted.

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

Well, Martin Fowler has gone on the record saying that Active Record (the design pattern, of which Ruby's ActiveRecord is one implementation) is not well-suited to sophisticated data models, and he tends to prefer the Data Mapper pattern — which similar to what's being described for Go.

expect it is quite hard to write a generic data mapper in go as well. something like Hibernate or Doctrine ORM would be nearly impossible to write with go.i'm not talking about the basic features but advanced features of both frameworks.

Re: Goji: a web microframework for Go

#38

Post by camus2 »

sagichmal wrote: post #30
gnaritas wrote: post #24

Earlier quoted context omitted.

Yuk, that's just manually doing what ORMs give you automatically; that's not a good thing, you're being a human compiler.

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translation of data and grammar, and as the type relationships grow more complex, ORMs fail. The lesson of ActiveRecord, from the perspective of Go, is that ORMs are fundamentally broken abstractions.

that's not the issue here, wether a pattern is good or not is irrelevant.The question is ,is it possible to write something like ActiveRecord and keep its most advanced features in Go. Right now the lack of genericity in the language makes it a no go.

Re: Goji: a web microframework for Go

#39

Post by gnaritas »

chc wrote: post #33
gnaritas wrote: post #32

Earlier quoted context omitted.

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

Well, Martin Fowler has gone on the record saying that Active Record (the design pattern, of which Ruby's ActiveRecord is one implementation) is not well-suited to sophisticated data models, and he tends to prefer the Data Mapper pattern — which similar to what's being described for Go.

That's not what the OP said, he said the lesson was "that ORMs are fundamentally broken abstractions". Fowler does not believe this, and even if he did, his opinion is certainly not a global lesson as if it were now best practice to consider ORMs fundamentally broken.

Re: Goji: a web microframework for Go

#40

Post by gnaritas »

Jweb_Guru wrote: post #36
gnaritas wrote: post #32

Earlier quoted context omitted.

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

I do, for one, but don't take my word for it... lots of very intelligent people have problems with ORMs. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute... presents a good summary of the problems involved (forgive the inflammatory title). Despite its many problems, SQL remains the best way of interacting with a relational database.

> lots of very intelligent people have problems with ORMs.

And lots of very intelligent people like them. Both statements are meaningless appeals to authority.

> Despite its many problems, SQL remains the best way of interacting with a relational database.

That's your opinion, it's certainly not a fact, and just as many disagree as would agree. Secondly, ORM's don't stop you from using SQL where it's beneficial, so ruling out the ORM because you don't like it for some cases is throwing out the baby with the bath water. For standard CRUD operations, ORM's are the best approach by far. Your hand written CRUD operations gain you nothing but extra work.

Post reply on HN