If you found this article, than you are probably similar to how I was a few months ago. I started a project in Go that required a SQL backend and I...
For further actions, you may consider blocking this person and/or reporting abuse
what do you think about gorm.io/ ?
burn it with fire, 8 levels deep nested reflection source code, a beginner's nightmare
I have never dived into that project, but that source sounds like a nightmare. Is the use of reflection that only way to pull off a library like that?
yea it requires parsing from struct tags for your custom structs but the problem with gorm is struct tag abuse and so many reflection caused by it
If you wanna skip SQL for an interview and wanna do very basic non-relational CRUD, it is the only use case of it.
Else, most of prod codebases uses standard library paired with sqlx or pgscan or sqlc lightweight approaches that only scans SQL results to given 1-by-1 fields with minimal "sql" struct tag parsing or with the help of Go type assertions on sql package types
I see, good to know what can be found in more real-world scenarios for Go and SQL.
Don't trust words alone. ~35k stars for Gorm repo should tell you something.
You can also check performance benchmarks: github.com/efectn/go-orm-benchmark...
It's not the best and not the worst.
Reflection is just another tool, that you shouldn't afraid.
Same thing is for Gorm, if you know where and how to use - go for it.
If not - it can be a good reason to learn/investigate.
True, I believe my first comment on this thread touches on this very sentiment that Gorm generally is considered the ORM for Go. There is no doubt that Gorm is very popular and used in a wide range of project sizes. Does that mean it was the best tool for them to use? Maybe, as the same could have been said for my project highlighted in the post (within the ent context).
Reflection is a tool, one that developers often are confused by (myself included) but I do not think its use equates to a "bad" product inherently. I whole hardheartedly agree, that any tool a developer is interested but unsure about should be investigated for them in the context of their use cases.
there are also other issues that other people don't point out since everyone(35k stars) is OK with mediocre performance(which is fine as long as code is maintainable) and not explicitly using SQL. Most of ORM users come from hibernate background(java/c#) and use things like eager loading or preloading (implicit SQL joins) this doesn't work well in Go package structure as it creates cyclic pkg dependencies. It is actually bad due to entity embedding, it goes against the language philosophy but if your aim is to make a product that works with mysql/postgresql at the same time and wanna ignore some of dialect based SQL, go for it. Most businesses will never pick this approach, furthermore gorm doesn't cover every SQL scenario like full text search. The inertia that devs built up by themselves in this last 10 years with ORMs is very dangerous as it creates a maintenance burden, your project can be as good as your dependecy, don't believe so much in the stars count
On the surface it is an amazing a truly amazing ORM tool that seems to have a very active and helpful community. Personally, I would avoid the using it for many of the same reasons as to why I have stopped using
entgo, it vastly complicates the code base and has great potential to be used improperly/inefficiently. Do you have personal experience with Gorm?