Hacker News new | comments | ask | show | jobs | submit login

Couldn't an ORM for Golang be done with a code generator that generates filter functions and such based on the table layouts and relations? Then you'd get the best of both worlds: "dynamic" operation in the sense that the methods vary depending on the table layouts and relations, plus static validation of what you're doing at compile time.

Go’s type system is still not powerful enough to express such a thing; ORMs depend on blending things together from all over the place, e.g. with joins, method chaining and other things which really need genuine generics. There really is no solution without generics.

Since Go can do generics via code generation [1], I'm not convinced that it can't also do ORM via code generation.

OTOH, I'm not particular fond of ORM as a universally right solution for dealing with DBs (its a solution which makes sense for some DB-related issues in some OO languages, but isn't something that should be reflexive "deal with DB, need ORM"), and its probably not a solution I would reach for for any problem in Go even whether or not you could reasonable do it in Go.

[1] https://github.com/droundy/gotgo

It seems to me that the method chaining is really all about building an internal S-Expression or tree structure of some kind that describes the type of query and joins needed. When it comes to solving problems, it's shaky ground to insist there can only be one possible approach.

Are you seriously suggesting that a statically typed language without generics can't do ORM?

What most mean by and expect of an ORM—yes.

Extensive use of reflection (in Go, this takes the form of type assertions) proceed to make it fundamentally possible again, but they have lost a lot of conciseness, certainty of safety and correctness in the process.

You can do it with code generation, though, right?

It depends. At the very most dynamic end, you'd encounter some troubles writing a code generator that could accommodate arbitrary joins of arbitrary combinations of tables chosen at runtime that happen to be for some reason arbitrarily joinable. This is an odd case, though; I'm sure somebody reading this has seen it and I sure it's out there, but it's probably not a case an ORM should be optimizing for. In most of the conventional uses, code generation could fit the bill, but you'd start getting into some weird declarations or something since you're not going to pre-generate every possible combination.

Personally, though, I've been migrating to "SQL calls" and "some support code to manage the rows coming back" even when not using Go. ORMs are this enormous pile of complexity, and it's amazing how easy it is to recover the vast bulk of their utility just by writing a bit of SQL. Use a decent SQL generator (as opposed to bashing strings together) and you're even closer. By no means is it a "full replacement", but I'm increasingly of the opinion that the costs of ORMs tend towards the staggering and the benefits minimal, for any nontrivial project. Possible exception for the really good ones that have been developed for a long time, but most of the ones used in the open source world are pretty dubious, IMHO.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact