9 comments

[ 1.2 ms ] story [ 22.6 ms ] thread
What I think I've always wanted an ORM in go to look like. Love the way that it declaratively defines schema and then enables client generation.
I've used most of the Go code generated ORMs and would have to say Ent is now my go-to for new projects. It works really nicely with gqlgen, handles permissions, and does eager loading.
I’m very interested to read an exemple mixing ent and gqlgen if by chance you knew an article. Thank you very much
Lol. Started development on the API for my new app and was looking for an ORM, found gorm first and then switched to ent just a few days ago. Suddenly it appears on hackernews.

I can really recommend it. It's been nothing but a pleasure. Only criticism would be the following: if you have a structure named ent/schema/*.go at the root of your project like they recommend, the code it generates lands in ent/ This isn't always great because it bloats the folder quite a bit. A separate folder for the generated code would be terrific.

How do you find the code generation flow? I would think it would be a bit disconcerting to have to generate tons of code every time you make a change.
Why doesn't GO have a try-catch blocks? Every file I see have dozens similar lines:

if err != nil { log.Fatal(err) }

In C# I can just log error on one place and transaction will be automatically rolled back. Much less code.

Go made the design decision to encourage checking for errors where they occur instead of catching exceptions somewhere down the line.