Constraints in Go

Not liking ORM I can understand, db table <-> object impedance mismatch is real, but "reducing boilerplate is bad" is an interesting take.

Can you elaborate and give some examples of why reducing boilerplate is generally "bad"?

Not the person you’re replying to. The orm sucks because as soon as you go out of the beaten path of your average select/insert/update/delete, you are inevitably going to end up writing raw sql strings. Two cases in point: postgres cte and jsonb queries, there are no facilities in gorm for those, you will be just shoving raw sql into gorm. You might as well stop pretending. There’s a difference between having something writing the sql and mapping results into structs. The latter one can be done with the stdlib sql package and doesn’t require an „orm”.

There are two things an sql lib must do to be very useful: prepared statements and mapping results. That’s enough.

You haven’t answered my question at all.

The parent comment made two claims: ORM not great (I agree) and “boilerplate reduction bad” which still needs some elaboration

Perhaps you have to yet use a good ORM? I could probably count on my fingers the times I had to drop to raw SQL in EFCore. Even when you do that you can still have mapped results, which reduces boilerplate.

What I mean is reducing boilerplate is not something one should strive to achieve. It is not bad in the sense that one should introduce more boilerplate for the sake of it. But reducing boilerplate for the sake of it is not good thing either.

If you need to make code more complex just to reduce boilerplate, it's a bad thing. If you managed go make code simpler and reduced boilerplate at the same time, it's a good thing.

And boilerplate might be a good thing when you need to type something twice and if you would make error once, the whole thing wouldn't work, so basically you'll reduce the possibility of typo. It might look counter intuitive. Just unrelated example: recently I wrote C code where I need to type the same signature in the header file and in the source file. I made mistake in the source file, but I didn't make the same mistake in the header file and the whole program didn't link. I figured out the mistake and corrected it. Without this boilerplate it's possible that I wouldn't notice the mistake and "helpful" autocomplete would keep the mistake forever. That's how HTTP Referer header made it into standards, I guess.

I answered it, you just don’t see it. One ends up with the boilerplate anyway as soon as one attempts to step out of the usual crud path. There’s no gain, there’s no difference in templating an sql string vs fighting an orm api.

I’m doing this job for 25 years and I haven’t seen a good orm. Sorry. Look, linq is nice. But linq is not enough of a productivity gain to switch the whole stack from go to .net. I used linq 15 years ago extensively and it feel like magic. But then again, how would you model jsonb select for a variable set of of properties and include nested or and and conditions using its notation? Maybe you could but how much longer is it going to take you rather than templating a string?

Any ORM worth it's salt has an escape hatch that allows you to do all those fancy raw SQL queries.

But the amount of queries that aren't fancy, and that an ORM is perfectly capable of abstracting away is (imho) 90% of all queries run.

Why make 90% or queries more tedious and error prone, just to make 10% slightly easier?

I've been doing this job for over 30 years and I agree.

Entity Framework was the thing that made me spit the dummy with C#, uninstall Windows, install Linux and discover Go in the first place.

Knowing how to write good SQL is a superpower as a developer, and every time I've worked with an ORM fan I get this reinforced. "The database is too slow!" No, your SQL just sucks.

Maybe people who have only ever used ORMs are happy with them, because they don't know how much more flexible and faster "raw" SQL queries can be?

I don’t even comprehend your argument. Look: https://gorm.io/docs/, it’s full of strings everywhere. That’s as error prone as anything else and it puts an additional layer of abstraction between you and your sql.

https://github.com/stephenafamo/bob supports both CTEs and JSONB in the psql (postgres) dialect

https://bob.stephenafamo.com/docs/query-builder/psql/example...

https://github.com/stephenafamo/bob/blob/main/gen/bobgen-psq...