> Ent heavily uses joins

I’m specifically talking about this: https://github.com/ent/ent/issues/977.

Devs assume that the `With` methods are adding join clauses but that is not typically the case.

> does support multi field indices

Composite primary keys are useful for reasons other than unique constraints and query speed. For example, CockroachDB uses the primary key to partition rows. Also, at scale, an extra multi-column index in addition to the primary key when the primary key alone could have sufficed can be a meaningful performance degradation.

> not a Graph DB under the hood

No it is not, but because it has a graph ‘mindset’ and does support Gremlin, traditional SQL folks expecting a lightweight ORM (such as Drizzle in the JS world) may not have a good time.

I just started coding in Go professionally over a year now. So far, that's the pattern that I'm seeing as well. I'm not really a fan. Some common answers on why to not use a lib is because it's trivial to rollout your own.

I like Go as a language but not so much on the community because of the reasons above. I just don't want to implement cache/cron for the n-th time again. I'd rather spending more time on building a new product instead, which is not the case when I'm using Go.

Can’t speak for buffalo but there are many libraries that have not been updated in a while and there’s a reason for that - they are complete.

There is no reason to update them, this isn’t nodejs that depends on one billion packages to do one thing where one of those changing basically affects any downstream users.

The std library is awesome, backwards compatible, and lots of libraries just add onto it. The interfaces are compatible and you can just keep your code simple.

I used to code a lot in Go. These days I’m back in node because it’s just easier for me to move faster. I’m also not doing anything with concurrency, so haven’t had a real need for Go

I think for core critical services I would use Go again just I haven’t needed to yet with my new project.