My work is mostly spent in JVM and .NET world and I am not a big fan of Go's design, so I am already biased.

However I am the first voice against ORMs in any project I work on.

If you care about performance, nothing beats tuned prepared stated going through the wire and stored procedures for heavy duty work.

In a few projects we improved batch processing times by a few hours just by throwing the ORM into the garbage can.

ORM works great for basic CRUD stuff like typical web applications. You don't have to use it in every part of your application.

Until you have the whole world banging into your site.

Not a problem that most people will have. If for some reason you do then hopefully you'll be able to monetize that popularity and hire someone who's actually really good it. ORM's are not optimal but they do let you make something quickly if you're not well versed in writing optimized queries, stored procedures, etc. For people like me dropping ORM's seem like a premature optimization.

> If you care about performance, nothing beats tuned prepared stated going through the wire and stored procedures for heavy duty work.

for "heavy duty work",sure.Now write your own hydrators,again,again and again,and let's see how maintainable your code is.

Now the fact is ,it's impossible to write an ORM in Go,without throwing all type safety,just like Java pre-generics,you'd cast and down-cast to Ojbect.

I don't even know what an hydrator is!

A hydrator populates an object from other data.

30 years of experience and never heard that in DB programming.

Thanks for the tip.

I'm the author of the post. I will be addressing this topic soon, but it's a very vast subject, it takes time to write good articles about database interactions and best practices.