Hacker News Reader

Comment by IceWreck | Hacker News Reader

Why is it that rust has so many good ORMs and go hardly has any production grade ORMs ? Lack of generics ?

When I tried to write one, I couldn't find a way to do it at compile time without generics. You can do it before compile time with code generation, or after compilation by coding dynamic objects and end up with something like sqlalchemy, but I couldn't do it at compile time.

ent [1] is what I've been happiest with. It uses code generation, and has an extension system so you can generate your own custom code with the models. I've seen a GraphQL extension and a REST extension, but haven't used either enough to comment beyond that they were easy to set up. Took like 20 minutes and now all my models transparently get GraphQL endpoints.

So far I've been happy with it, but we'll see in a couple of years.

1. https://entgo.io/

SQLx is amazing. Can't do much better without replacing SQL itself.

One remaining problem is writing dynamic queries without giving up static verification completely.

For example, optional WHERE, ORDER BY, GROUP BY clauses are very common. Currently the solutions are:

* Give up and write a fully dynamic query. * Generate every possible permutation. Combinatorial explosion quickly makes this impractical. * Write a static query without the optional clauses, then add clauses and execute a dynamic query. The best of both worlds but complicated.

However the optional clauses are almost always independent from each other. It should be possible to statically verify each one with `SELECT NULL FROM <full set of JOINs> WHERE/ORDER BY/GROUP BY <optional clause>`.

I'm working on a PoC static SQL query builder using generics, but it's pretty opinionated and kinda assumes that the binary is controlling the DB, instead of the DB being independently managed. And since it's static, it would generate every possible reachable permutation at compile time, so yeah :/

EDIT: Now that I think about it, you could have a partially dynamic query that's still statically checked: new WHERE conditions don't change the structure of the query, so as long as they're valid (which can be statically checked) they can be added to the query without changing the type. Same for e.g. ORDER BY or LIMIT. That would make the combinatorial explosion much more manageable, and it would actually represent different code paths (requesting a different set of fields).

The list with fixed formatting:

* Give up and write a fully dynamic query.

* Generate every possible permutation. Combinatorial explosion quickly makes this impractical.

* Write a static query without the optional clauses, then add clauses and execute a dynamic query. The best of both worlds but complicated.

From my personal experience the engineers I’ve worked with who are using Go seem to prefer writing SQL. The community doesn’t seem to like using external libraries over the standard library. Not always but that seems to be the preference.

> From my personal experience the engineers I’ve worked with who are using Go seem to prefer writing SQL.

For what it's worth, a very popular Rust framework (also named SQLx lol) is designed around pure SQL tool.

Personally i think both languages have roughly the same split of SQL vs ORM people. However Rust gives devs way more tooling to to invent, to choose runtime cost, etc. So some types of libraries are just easier in a "complex" language imo.

Reply on news.ycombinator.com