As an Ent user, I’m surprised to see that as the default ORM. It is graph oriented for better and for worse. No composite primary keys for ‘nodes’ and minimal use of joins (no use?) in the underlying generated SQL. The DX is great, but GORM is a better default IMO.
Nonetheless, great to see a new serious Go meta framework.
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
Has anyone tried both Pagoda and GoBuffalo and can compare?
GoBuffalo recently archived their github project and basically become unmaintained, which is extremely sad for such a mature framework used in production by many.
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.
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?
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.
As an Ent user, I’m surprised to see that as the default ORM. It is graph oriented for better and for worse. No composite primary keys for ‘nodes’ and minimal use of joins (no use?) in the underlying generated SQL. The DX is great, but GORM is a better default IMO.
Nonetheless, great to see a new serious Go meta framework.
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
Has anyone tried both Pagoda and GoBuffalo and can compare?
GoBuffalo recently archived their github project and basically become unmaintained, which is extremely sad for such a mature framework used in production by many.
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.
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?
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.
Looks impressive, and the docs are thorough. Nice work!