I am not a fan of ORMs. Application performance problems are usually down to poorly formed SQL queries (and/or lack of supporting indexes), which ORMs can mask or amplify.
For an alternative approach, have a look at https://github.com/sqlc-dev/sqlc In short, you write the set of SQL queries to meet your application's needs, and then they get automatically wrapped in idiomatic Go. For joins, see: https://docs.sqlc.dev/en/stable/howto/embedding.html Refs: https://conroy.org/introducing-sqlc https://sqlc.dev/ https://play.sqlc.dev/ https://alanilling.com/exiting-the-vietnam-of-programming-our-journey-in-dropping-the-orm-in-golang-3ce7dff24a0f On Thursday, 19 December 2024 at 13:01:25 UTC Bhavesh Kothari wrote: > I read few posts regarding ORMs in golang & realized, few peoples are not > happy with it. > > They mentioned to use raw queries with our own wrapper if want to make few > things reusable. > > I was actually using Gorm, which was super slow, then I started research > regarding performance efficient ORMs, and found *Bun* which was indeed > faster compared to Gorm. But then I explored documentation more and > realized it doesn't provide enough function to make life easier, this ORM > even doesn't have community I felt. > > 1. I want to know readers view regarding ORMs in Go. > > Let me tell you something, my project is a huge project, and I decided to > use Golang for better performance. But now I feel I've to write a lot of > code and slow/less-featured ORMs here making me irritated. > > 2. What do you guys suggest is go really good for large projects? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/6addef83-3e2d-4b6c-b543-8127f5754f0en%40googlegroups.com.
