I’m a started golang early this year and I’ve used it to create APIs using gorilla mux and gorm. And also created recommendation engine using gorse. I will sincerely appreciate if I can network with someone that can get me any job opening or gig
I beg to differ. First off, raw SQL queries in your code are a great way to: 1) make your code readability suffer 2) introduce unchecked code that is basically stored in a string, so there's no guarantee it works 3) restrict your project to a specific DBMS 4) introduce potential vulnerabilities and so on. Also, SQL is highly declarative and SQL interpreters mostly don't care about how the query is structured. If you want to really "optimise" an SQL query to make it faster by modifying it, that's done in very non-obvious ways and is closer to randomly restructuring the query than to anything else, so it's safe to say that the structure of the SQL queries does not really affect their performance, and generating the queries with an ORM does not take significant time either.
I think Go ENT is the way to go if you’re using ORM. It’s entity framework for Go open sourced by META, which provides simple API for modeling any database schema as a Go object. Also, it’s easily traverse any graph structure since it’s graph-based framework. And most importantly it’s 100% statically typed and generates fully secure code for accessing and manipulating DBs. Go ENT is even more performant compared to GORM.
That looks complicated as hell. What are the advantages of ENT over not using SQL (which is what ent is built on) but going with MongoDB straight away?
There are a lot of articles that talk about the importance of mainting certain context in programming and the penalty (mentally speaking) that comes with switching from one context to another, for instance, from Go to SQL, from SQL to docker, etc. I think ORMs serve very well that purpose. I also agree in that they come with a small performance cost, but being realistic, probably the great majority of apps doesn't app require us to squeeze it to the last milisecond of latency. I think readibility should come first when it comes to small or medium projects, for large projects probably architecture problems are more of a worry compared to whether the app uses or not an ORM. By the way, I love your videos, I always learn new things! keep up the good work and thank you for creating content for us.
i would love using gorm when developing a really big project with complex or complicated database query because it more easier and readable using orm than the raw query
Funny thing about ORMs. Always somebody complaining about them. Just about every modern language has at least one. I guess there must be use cases for them then? No one writes these things for nothing. Of course there are times when you need tweaked raw SQL for certain applications but for most things you really don't...
I have used gorm on many projects with gin and fiber. It never caused any problem to me rather made development quicker. the problems you mentioned is true to every other orm out there in other technologies too.
Honestly most go libraries have terrible documentation and gorm is a step above . I usually end up having to step into the source code and see what it does .
Misleading title. The reasons mentioned here are reasons why go developers would hate AN orm mapper, not Gorm specifically. None of these culprits are exclusive to Gorm. I'm a fan of rawsql myself, but then you gotta consider the security (sql injection preventation), db migration and all kinds of other fun stuff that an ORM handles for you out of the box. So as with most things, it's a tradeoff.
as someone who used both i prefer to use orm in certain situation its not like the orm forces you to use it. type safety and simple short queries validation middleware is where i mainly use it if the query is expected to be long i just use function queries within the database it self. orm is only bad when your still typing the table names manually or still escaping string manually
Our company created soft realtime infrastructure paymeny with golang and gorm and event driven architecture . That is one of fastest infra in our country between payment companies. We use gorm for model first approach and great migration system for complex systems . Just our big issue was gorm new version heavily changed and produced some issue in our system
Thanks for changing the voice. You are really knowledgeable no doubt but your accent is hard to understand. Thanks for listening to feedback. Now I will watch your content for sure
I have tried entgo. The team I work with really liked the entity representation, but very quickly we realised it's not helping. As time went on, it became much easier to just write raw SQL, because we needed a lot of complex joins, mostly joins that ent doesn't support...
This video is much too shallow. ORM's are bad because they are not good at dealing with overly complex queries compared to a programmer? JOINS of any kind and overly complex queries should be avoided at all cost anyway. Anyone needing those should probably spend more time on their database architecture than on writing magic 15-line queries. ORMs really level up the dev experience and provide a uniform abstraction layer. Working on a bigger project I with multiple people I would always recommend using one. I think GORM does a good job as a minimal library although the documentation is a bit lacking.
JOINS of any kind and overly complex queries should be avoided at all cost anyway? How laughable. What about CTE's? Window functions? Material Views? Recursive queries? Table partitioning? Custom Aggregates? Your database doesn't need an abstraction layer. It needs someone who doesn't think it's a weird file system or a GUI-less spreadsheet. If all your building is toy CRUD apps then just use an unstructured key value store and leave relational databases to those that understand them.
because they generate go files, with no dependency on the sql compiler. sqlc takes your schema, and a file containing queries and converts it into model structs, and a query struct. The end result is vanilla go with no external dependencies.
There is a limited amount of tens of hours I'm willing to put into debugging stupid errors like `ERROR: column "manufacturername" does not exist (SQLSTATE 42703)`. That amount is 3. Screw GORM and screw ORMs. Never again. Literally lost 5 days of work to it.
for initiate database gorm is good, but for migration maybe not yet.... how if we would change structure of table ex: rename column, delete column that we design before. What happen with our data ?
So I use gorm without the relations . I just use it for basic crud and batch creates etc . the rest of the relations I'll just hand write the sql query that does the join . I dont like sqlx because the structure binding is way too strict . and I sometimes want to scan to map[string]interface{} . so I have to use gorm otherwise I have to use sql.db and write 10 lines for a get me something query .
Libraries like GORM/ENT makes you weak in programming/design and it also reduces your problem solving abilities. That means less chance you will get hired by FAANG type companies as these companies hire only engineers who don't rely on third party libraries like GORM/MUX etc.
@@someoneanonymous6707 In doing that, developer just learns framework/library and not programming. Ironically, majority of product companies like Google/Apple discard the resume if you say "I am using xyz framework"
No it doesn't. Using a library means you save time and can focus on solving the problem at hand and don't have to rely on reinventing the wheel again. Also, using GORM it makes it super easy to change to use MSSQL, Postgres, SQLite or MySQL databases without having to bother with the SQL differences. This is very handy because you most likely don't care about the nuances in SQL for the different databases.
@@makesnosense6304 Don't care about nuances in SQL? But interviewers ask inner/outer join questions and ask you to design database for full stack positions. Saving time, yes but startups and FAANG companies are less likely to hire developers who use frameworks/libraries. There will be some exceptions ofcourse.
Get your *FREE Golang Cheat Sheet* -
golangdojo.com/cheatsheet
why hate it ? I've done a lot of projects using gorm and earned money from it XD
I’m a started golang early this year and I’ve used it to create APIs using gorilla mux and gorm. And also created recommendation engine using gorse. I will sincerely appreciate if I can network with someone that can get me any job opening or gig
I love gorm not as an orm, but as a quick and dirty db migration tool that allows making database creation and recreation hidden from a user
I beg to differ. First off, raw SQL queries in your code are a great way to:
1) make your code readability suffer
2) introduce unchecked code that is basically stored in a string, so there's no guarantee it works
3) restrict your project to a specific DBMS
4) introduce potential vulnerabilities
and so on. Also, SQL is highly declarative and SQL interpreters mostly don't care about how the query is structured. If you want to really "optimise" an SQL query to make it faster by modifying it, that's done in very non-obvious ways and is closer to randomly restructuring the query than to anything else, so it's safe to say that the structure of the SQL queries does not really affect their performance, and generating the queries with an ORM does not take significant time either.
100% agree
Normally, it's solved architecturally. Isolate all DB access to repository classes.
It also ensures consistency across your codebase...
I think Go ENT is the way to go if you’re using ORM. It’s entity framework for Go open sourced by META, which provides simple API for modeling any database schema as a Go object. Also, it’s easily traverse any graph structure since it’s graph-based framework. And most importantly it’s 100% statically typed and generates fully secure code for accessing and manipulating DBs. Go ENT is even more performant compared to GORM.
Thanks for the heads up on this, will check ENT out.
That looks complicated as hell. What are the advantages of ENT over not using SQL (which is what ent is built on) but going with MongoDB straight away?
Ent is unnecesaary complications and generates code without even asking. Varchars are a mess too.
On every video you say to get your cheatsheet, then when I go to the link, it doesn't work.
There are a lot of articles that talk about the importance of mainting certain context in programming and the penalty (mentally speaking) that comes with switching from one context to another, for instance, from Go to SQL, from SQL to docker, etc. I think ORMs serve very well that purpose. I also agree in that they come with a small performance cost, but being realistic, probably the great majority of apps doesn't app require us to squeeze it to the last milisecond of latency.
I think readibility should come first when it comes to small or medium projects, for large projects probably architecture problems are more of a worry compared to whether the app uses or not an ORM.
By the way, I love your videos, I always learn new things! keep up the good work and thank you for creating content for us.
i would love using gorm when developing a really big project with complex or complicated database query because it more easier and readable using orm than the raw query
- do you hate GORM
+ yes
- are you using it
+ yes
Funny thing about ORMs. Always somebody complaining about them. Just about every modern language has at least one. I guess there must be use cases for them then? No one writes these things for nothing. Of course there are times when you need tweaked raw SQL for certain applications but for most things you really don't...
I have used gorm on many projects with gin and fiber. It never caused any problem to me rather made development quicker. the problems you mentioned is true to every other orm out there in other technologies too.
A back-end developer that doesn't know SQL is a like a front-end developer that doesn't know CSS
100% I agree, we hate gorm
Also the documentation sucks
Honestly most go libraries have terrible documentation and gorm is a step above . I usually end up having to step into the source code and see what it does .
why golang devs do we hate everything? Lol jaja xD
I hate ginkgo test library so much.
i hate it too XD
Misleading title. The reasons mentioned here are reasons why go developers would hate AN orm mapper, not Gorm specifically. None of these culprits are exclusive to Gorm.
I'm a fan of rawsql myself, but then you gotta consider the security (sql injection preventation), db migration and all kinds of other fun stuff that an ORM handles for you out of the box. So as with most things, it's a tradeoff.
as someone who used both i prefer to use orm in certain situation its not like the orm forces you to use it. type safety and simple short queries validation middleware
is where i mainly use it if the query is expected to be long i just use function queries within the database it self. orm is only bad when your still typing the table names manually or still escaping string manually
Sqlc is probably a much better alternetive to gorm.
Our company created soft realtime infrastructure paymeny with golang and gorm and event driven architecture . That is one of fastest infra in our country between payment companies.
We use gorm for model first approach and great migration system for complex systems . Just our big issue was gorm new version heavily changed and produced some issue in our system
What did gorm do he is a good youtuber
Thanks for changing the voice. You are really knowledgeable no doubt but your accent is hard to understand. Thanks for listening to feedback. Now I will watch your content for sure
Does Tommy have a UA-cam channel?
what about entite library like entgo?
I have tried entgo. The team I work with really liked the entity representation, but very quickly we realised it's not helping. As time went on, it became much easier to just write raw SQL, because we needed a lot of complex joins, mostly joins that ent doesn't support...
This video is much too shallow. ORM's are bad because they are not good at dealing with overly complex queries compared to a programmer?
JOINS of any kind and overly complex queries should be avoided at all cost anyway. Anyone needing those should probably spend more time on their database architecture than on writing magic 15-line queries.
ORMs really level up the dev experience and provide a uniform abstraction layer. Working on a bigger project I with multiple people I would always recommend using one. I think GORM does a good job as a minimal library although the documentation is a bit lacking.
JOINS of any kind and overly complex queries should be avoided at all cost anyway? How laughable. What about CTE's? Window functions? Material Views? Recursive queries? Table partitioning? Custom Aggregates? Your database doesn't need an abstraction layer. It needs someone who doesn't think it's a weird file system or a GUI-less spreadsheet. If all your building is toy CRUD apps then just use an unstructured key value store and leave relational databases to those that understand them.
Any recommended Type safe Query builder other than go-jet , go-structured-query, sqlc _
ent by meta
No I works and like gorm with associations I have no issue
sql compiler video please
How is an sql compiler not just another dependency along side Go?
because they generate go files, with no dependency on the sql compiler. sqlc takes your schema, and a file containing queries and converts it into model structs, and a query struct. The end result is vanilla go with no external dependencies.
There is a limited amount of tens of hours I'm willing to put into debugging stupid errors like `ERROR: column "manufacturername" does not exist (SQLSTATE 42703)`. That amount is 3. Screw GORM and screw ORMs. Never again. Literally lost 5 days of work to it.
for initiate database gorm is good, but for migration maybe not yet.... how if we would change structure of table ex: rename column, delete column that we design before. What happen with our data ?
node started with dislike of orm now people just use orm but still have a pure sql style or just pure orm
How dare you hate the furcorn goomba >:(
GORM can also run a raw SQL. What about Ent?
Why Mika Fans Hates GolangDojo...
Who's this tommy guy? is ha a youtuber too?
So I use gorm without the relations . I just use it for basic crud and batch creates etc . the rest of the relations I'll just hand write the sql query that does the join . I dont like sqlx because the structure binding is way too strict . and I sometimes want to scan to map[string]interface{} . so I have to use gorm otherwise I have to use sql.db and write 10 lines for a get me something query .
its getting people mad when migrating your system to a shit database that gorm does not support
haizzz, I struggling in create generic repository in gorm
gorm is very slow
Thank you
Too bad there is no equivalent for hibernate with HQL in go world.
any one tried sqlc?
but I love gorm.
Libraries like GORM/ENT makes you weak in programming/design and it also reduces your problem solving abilities. That means less chance you will get hired by FAANG type companies as these companies hire only engineers who don't rely on third party libraries like GORM/MUX etc.
The entire idea of ORM is to code fast and with fewer mistakes which from a professional point of view is gold as it is saving time.
@@someoneanonymous6707
In doing that, developer just learns framework/library and not programming. Ironically, majority of product companies like Google/Apple discard the resume if you say "I am using xyz framework"
you think it's 2005 or something? I hope you are writing all your code in assembly too, you weak programmer ;)
No it doesn't. Using a library means you save time and can focus on solving the problem at hand and don't have to rely on reinventing the wheel again. Also, using GORM it makes it super easy to change to use MSSQL, Postgres, SQLite or MySQL databases without having to bother with the SQL differences. This is very handy because you most likely don't care about the nuances in SQL for the different databases.
@@makesnosense6304
Don't care about nuances in SQL? But interviewers ask inner/outer join questions and ask you to design database for full stack positions. Saving time, yes but startups and FAANG companies are less likely to hire developers who use frameworks/libraries. There will be some exceptions ofcourse.
I always learn something new here, thanks ninjas