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

Macaron: a high productive and modular web framework in Go

go-macaron.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Macaron: a high productive and modular web framework in Go

#41

Post by Thaxll »

bsaul wrote: post #8
virmundi wrote: post #2

I quickly looked this over. Does Golang have some hidden ORM like feature that makes complex persistence easy? I spent the last three months working on a storage mechanism that controls all of CRUD at the document level across what is essentially Google Groups (each op is allowed to multiple groups). This is where web work is complex.

Came here to say the same thing. Go won't enter "crud webapp" market until they have a better story on relational db interactions. I'm afraid this is way beyond the current possibilities of the language as it offer barely any meta-programming technics, on purpose.

None of the company I worked for had any ORM like in place and they were all doing crud app.

Re: Macaron: a high productive and modular web framework in Go

#42

Post by whoiskevin »

0xCMP wrote: post #39
whoiskevin wrote: post #25

Starting to feel like Go is suffering from a glut of web frameworks.

This framework has been around forever and not really. Most people use the standard library unless they need better routing than the standard library provides. There are actually very few web frameworks that provide much other than a router in Go. Most of the frameworks are actually just packages that can be used for all sorts of things. e.g. Beego by astaxie

Well I wasn't commenting on age of particular projects. I had not heard of Beego so now I still feel there is a bit of over growth. Leads to confusion over what to use when you do want better routing which I think is pretty much every project. Perhaps routing will continue to improve in the standard library such that it does not feel like I need to pick a package or roll my own.

Re: Macaron: a high productive and modular web framework in Go

#43

Post by bsaul »

Thaxll wrote: post #41
bsaul wrote: post #8

Earlier quoted context omitted.

Came here to say the same thing. Go won't enter "crud webapp" market until they have a better story on relational db interactions. I'm afraid this is way beyond the current possibilities of the language as it offer barely any meta-programming technics, on purpose.

None of the company I worked for had any ORM like in place and they were all doing crud app.

i've seen companies forbid the use of ORMs by fear that developpers will abuse lazy loading and collapse the db instead of using inner joins ( which any decent orm is able to do btw).

It could make sense in some context, and i'm pretty sure that any sufficiently advanced service has so many custom and optimized queries that an ORM doesn't make a difference.

however IMHO, ORMs do play a very important role in the beginning of the project when prototyping screens and apis, and when rapid iteration is important. It isn't a coincidence that RoR advertized active record as much, that symfony use doctrine in all tutorials, and that java , .net and node.js frameworks all include an ORM component.

Re: Macaron: a high productive and modular web framework in Go

#44

Post by camus2 »

whoiskevin wrote: post #25

Starting to feel like Go is suffering from a glut of web frameworks.

It's a simple http router, it just filter requests and assign them to an handler, it's hardly a framework like Symfony, Laravel, Django, Rails or Spring. People need to stop calling http routers "frameworks".

People are going to write code for multiple reason. You can't complain about people writing opensource code, you're not forced to use it.

Re: Macaron: a high productive and modular web framework in Go

#45

Post by weberc2 »

bsaul wrote: post #38
weberc2 wrote: post #27

Earlier quoted context omitted.

We use SQLalchemy at work and I would rather write queries by hand. A lot of that is because the documentation is a huge pain, but also because the object composition isn't intuitive. I've built a profile query builder in Go and it was pretty straight forward; I'm confident I could build an ORM in a couple of weeks.

sqlalchemy ( which i used and liked a lot) has multiple layers. query builder is the bottom one, but the most "challenging" one for go is probably the orm with things lazy loading and its parametrization ( such as eager loading of relationships). keeping it all type safe ( not having the user cast interface{} to struct everywhere) and performant would be a challenge.

I'm not sure exactly what you mean about parameterization, but I suspect in general my notion of what an ORM is differs from yours (in particular, I don't assume lazy loading). Maybe what I'm thinking isn't appropriately called "ORM" (maybe "type relational mapping" is more appropriate?). At any rate, I don't think type safety should be a challenge (somehow a mapping must be generated for each type, just like SQLAlchemy--in Go this can be either explicit or inferred once via reflection or code generation) and I don't think performance would be more a challenge in Go than any other language (the trick to ORM performance is in building efficient SQL queries, not in reflection or type asserts).

Re: Macaron: a high productive and modular web framework in Go

#46

Post by jdc0589 »

heavenlyhash wrote: post #36
virmundi wrote: post #2

I quickly looked this over. Does Golang have some hidden ORM like feature that makes complex persistence easy? I spent the last three months working on a storage mechanism that controls all of CRUD at the document level across what is essentially Google Groups (each op is allowed to multiple groups). This is where web work is complex.

I've been experimenting with a library called `refmt` which does the O bject M apping part, but explicitly not the R elational part. It's still experimental, but you might like it, and test coverage is shaping up nicely. The idea is by focusing completely on making Object Mapping consistent and powerfully customizable, and then composing that with either serialization formats or relational storage, we'll get good thi…

object mapping is the most important part of the ORM experience in my opinion. Writing DB queries isn't hard or even annoying, manually doing model binding constantly is frickin infuriating.

Re: Macaron: a high productive and modular web framework in Go

#47

Post by urethrafranklin »

whoiskevin wrote: post #25

Starting to feel like Go is suffering from a glut of web frameworks.

A lot of web developers learned it, and a very natural tendency is to use a new medium in service of the old paradigm. The first tv broadcasts were a bunch of guys sitting at a table, reading the news just like they did on the radio.

Re: Macaron: a high productive and modular web framework in Go

#48

Post by simooooo »

weberc2 wrote: post #27
bsaul wrote: post #13

Earlier quoted context omitted.

sqlx didn't work in my case last time i tried (don't remember why exactly), but it's still far from any standard like sqlalchemy (python), hibernate (java) , active records (ruby),entity framework (.net), doctrine (php) or bookshelf (js). Writing every select for every entity, with all the variations depending on whether you want to inner join with 1-n relationships (and which ones) is really tedious when you've got…

We use SQLalchemy at work and I would rather write queries by hand. A lot of that is because the documentation is a huge pain, but also because the object composition isn't intuitive. I've built a profile query builder in Go and it was pretty straight forward; I'm confident I could build an ORM in a couple of weeks.

You could do in weeks what has taken the hibernate folks years and years?

Re: Macaron: a high productive and modular web framework in Go

#49

Post by bsaul »

weberc2 wrote: post #45
bsaul wrote: post #38

Earlier quoted context omitted.

sqlalchemy ( which i used and liked a lot) has multiple layers. query builder is the bottom one, but the most "challenging" one for go is probably the orm with things lazy loading and its parametrization ( such as eager loading of relationships). keeping it all type safe ( not having the user cast interface{} to struct everywhere) and performant would be a challenge.

I'm not sure exactly what you mean about parameterization, but I suspect in general my notion of what an ORM is differs from yours (in particular, I don't assume lazy loading). Maybe what I'm thinking isn't appropriately called "ORM" (maybe "type relational mapping" is more appropriate?). At any rate, I don't think type safety should be a challenge (somehow a mapping must be generated for each type, just like SQLAlch…

compile-time code generation can only get you so far, unless you're ready to generate every single kind of query beforehand ( which grows exponentially with the number of -to-many relationship). You'll have to rely on introspection but i suspect things won't go smoothly.

anyway, it should make for a good exercise i'm sure.

as for the definition of Object-Relationnal-Mapper the idea is to completely abstract the fact that you're storing your object graph ( or struct graph in the case of go) in a relationnal database. To do so, the developper provides meta data , like an xml file or annotation, to describe the mapping. This is a pretty hard problem.

Post reply on HN