Hacker News Reader

Comment by misiti3780 | Hacker News Reader

Python : Django === Go : ??

If I want a nice ORM and built in migrations, what framework should I be using 10 years later?

I wasn't happy with the current database access packages (https://github.com/jmoiron/sqlx, https://gorm.io), so I wrote my own for PostgreSQL. It takes existing queries and generates type-safe Go methods (https://github.com/kyleconroy/sqlc). I enjoy using it and thought others might too.

As for migrations, I've had success with https://github.com/pressly/goose. It's lightweight and is also just SQL.

Nice, much like people would use Pro*C to generate C to talk to Oracle. I think converting a DSL to boilerplate (which should rarely be read and never edited) is key to living with a language that isn't good at reusable abstractions.

I've been using Darwin(1) for migrations, personally.

^1: https://github.com/GuiaBolso/darwin

You don't have a single famous one because Go developers tend to hate frameworks and ORM's. If you are interested, I have wrote about some alternatives before here - https://hackernoon.com/the-myth-about-golang-frameworks-and-...

The actual reason is that the language lacks the meta-programming facilities required for creating effective ORMs and certain frameworks. (Whether this is a good thing or a bad thing is a subjective matter.)

Exactly. There's not much choice. The best approximations are considered hacks.

Wait, is that true? I thought that the Java packages like Hibernate were just using method attributes and reflection...doesn't Go have the ability to add attributes to structs and a working reflection library?

They use generics pretty heavily too so it's not only reflection. Generics allow them to do a typesafe interface for the developer to use as well as making less work for the reflection code to do.

And annotations and classloaders. Haven't looked at Hibernate in years ("10 years" to be exact /g) but it is possible that it also requires Java and JVM's instrumentation facilities. So certain kind of software magic can't be done with Go.

Options in Go for effective ORM require source level processing.

Yes, Go has a reflection package, but it's terrible. Nowhere near has the power compared to Python's metaprogramming capabilities.

Go has reflection, but it doesn't have annotations or generics. Annotations are key for libraries such as hibernate.

Aren't `tags` akin to annotations?

No, Go tags are like metadata which can be accessed through reflection at runtime. Java annotations allow you to actually generate code during the build phase.

I've encountered a bunch of code generation in client-go - I'm not very good at Go, so not sure what the term for the code generation directives in comments is, if there is one.

sqlx (1) is probably the closest thing to a tradition ORM that operates this way

^1: https://github.com/jmoiron/sqlx

I'm not sure that's really a showstopper if you really want to do it? Code generation is powerful and it can be done outside the language.

I don't believe that to be true. There are almost too many ORMs for Golang.

Golang has had an issue with fractured ecosystems from the start. Part of this had to do with lack of a package manager. Part of it had to do with companies and developers wanting to move fast and not get bogged down trying to get changes through other peoples process and into their repo. Or perhaps development stalled out as the ORM met the requirements of the developers/project, or for other reasons.

If you evaluate carefully each of the available ORMs it becomes apparent that a lot of them have different short comings and trade-offs, and were created around some theme or feature set missing from the others.

Buffalo (https://gobuffalo.io/) seems to be getting popular but can't speak from personal experience

I think in the past 10 years there's been a real move away from ORM so I wouldn't expect it in the Go ecosystem. SQL is the best way to interface with a RDBS.

Yeah, untyped syntax inside your statically typed language, what could be better.

What's preventing you from using a query builder?

Then the accurate thing to say is "a SQL query builder is the best way to interface with a RDBS"

As a query DSL I don't find a problem with that. It's like saying that query strings in urls are untyped so don't match well. In reality the gap between untyped->typed is super narrow. You almost always immediately scan the results of your query into typed struct fields.

I haven't seen that at all. Every popular open source project that comes to mind uses an ORM in some form or fashion. I'm sure they exist but I can't think of a single one that is just doing raw SQL or Query building, across any programming language for that matter. Heck, I think GOGS/GITEA are the reason xorm even exists. There are a number of ORMs for golang, they just all have their pros and cons.

Not a framework, but I wrote a migration tool compatible with several SQL databases: https://github.com/egtann/migrate.

It ensures consistency can always be reached (the most important feature for a migration tool IMO, yet most tools do not guarantee this) and uses standard SQL syntax in migration files.

I am in the “we don’t need an ORM camp” but what I need instead is a flexible query builder. Like knex for JavaScript. I have yet to find that one.

Does Squirrel cover your needs?

https://github.com/Masterminds/squirrel

I was using Squirrel and goqu extensively. Both are nice, not as easy and flexible as knex. That is basically a language constraint, JavaScript’s dynamic typing allows for all kinds of shortcuts Go cannot offer.

I highly recommend you check out elixir + phoenix

Reply on news.ycombinator.com