Ent heavily uses joins and does support multi field indices, you should read up on the docs. You can show the queries it’s running using a debug client.

It’s not a Graph DB under the hood and uses any normal relational db quite normally beneath the DX

Same here. Go community has a tendency of not using frameworks as much (which I guess is confirmed by the lack of long term maintenance for a lot of Go frameworks), compared to say Ruby. I don't think that is a bad thing. We ended up using Gorm as one of the few frameworks for our web stack and I personally have mixed feelings about it.

On the one hand, it's a very comprehensive ORM (support for different DBs and types of queries, joins, associations, etc). On the other hand, the documentation is not very good and often its behavior leaves you baffled (updates of columns and the associates in different times, for example).

Overall, I think I'd still choose an ORM over writing SQL or quasi-SQL in the code for the sake of maintainability and readability of the code. GORM is the best one around but I wish there were more options.

Agreed - surprised gorm or something a little more mature wasn't used.

I discarded the HTMX stuff - the rest of the framework is nicely put together. The ability to queue worker items to asynx workers as well as the ability to add CLI commands to CRUD on the DB helped get a project going in quick time.

This is how things get adopted, it's not usually overnight.

HTMX has been more than good enough all along for the applications it can help with.

I don't use HTMX, but I use Turbo (which is what htmx is based on) in Rails daily for web apps that are in production at scale. Its in my opinion the future of web development.

Is this common in Go?

Just this week I was examining moving my early stage stack to Golang, but I repeatedly came across highly recommended packages that were dead. Gorilla had apparently died but come back in some capacity, Echo seems to be actively dying as PRs aren't being addressed, Buffalo was an option I looked at and is now archived

Does the "just use the stdlib" mentality mean everyone is just rolling the glue layers on their own 1000x over?

It's often the change that happens with experience. Most developers join Go looking for their Laravel, Rails, Next.js, Spring framework. Because it's almost impossible to write something in those languages without a framework.

In Go, the longer you use it, the more you realize "just use the stdlib" actually works for most things. A lot of these projects die because most Go devs either 1) need a mux and use httprouter or gorilla or 2) need a more robust multi-instance setup (go-kit, goa.design, smithy, etc..)

Most big projects just don't use a MVC (or otherwise framework) as it's more work to use, update and understand than just writing your own glue for the libraries you do need.

I might have explained this poorly, but I like to think of Go as a collection of packages where other languages are a collection of frameworks because the packages can't be used together easily and need organization on top to ensure everything works.

I found Pagoda required me to juggle too many things that were only loosely coupled together.

GoBuffalo was great but as soon as I started using, it got archived :’)

Now I default to beego. It isn’t as batteries included as a rails or django app, but there’s enough there that I don’t have to write as much boilerplate as with only the stdlib.