←back to thread

Constraints in Go

(bitfieldconsulting.com)
210 points gus_leonel | 10 comments | 17 Nov 24 08:44 UTC | HN request time: 0.001s | source | bottom
Show context
indulona ◴[17 Nov 24 09:59 UTC] No.42163167[source]▶
i have been writing Go exclusively for 5+ years and to this day i use generics only in a dedicated library that works with arrays(slices in Go world) and provides basic functionality like pop, push, shift, reverse, filter and so on.

Other than that, generics have not really solved an actual problem for me in the real world. Nice to have, but too mush fuss about nothing relevant.

replies(10): >>42163189 #>>42163244 #>>42163415 #>>42163694 #>>42163834 #>>42164296 #>>42164983 #>>42165141 #>>42165270 #>>42165680 #
throwaway63467 ◴[17 Nov 24 10:03 UTC] No.42163189[source]▶
Honestly so many things profit from generics, e.g. ORM code was very awkward before especially when returning slices of objects as everything was []any. Now you can say var users []User = orm.Get[User](…) as opposed to e.g var users []any = orm.Get(&User{}, …), that alone is incredibly useful and reduces boilerplate by a ton.
replies(3): >>42163242 #>>42163295 #>>42168753 #
vbezhenar ◴[17 Nov 24 10:21 UTC] No.42163242[source]▶
ORM is anti-pattern and reducing boilerplate is bad.
replies(5): >>42163314 #>>42163315 #>>42163626 #>>42163744 #>>42168321 #
bobnamob ◴[17 Nov 24 12:06 UTC] No.42163744[source]▶
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"?

replies(2): >>42163929 #>>42164240 #
1. rad_gruchalski ◴[17 Nov 24 12:47 UTC] No.42163929[source]▶
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.

replies(4): >>42163980 #>>42164006 #>>42167612 #>>42210541 #
2. bobnamob ◴[17 Nov 24 13:00 UTC] No.42163980[source]▶
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

replies(1): >>42164432 #
3. metaltyphoon ◴[17 Nov 24 13:06 UTC] No.42164006[source]▶
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.
replies(1): >>42164459 #
4. rad_gruchalski ◴[17 Nov 24 14:44 UTC] No.42164432[source]▶
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.
5. rad_gruchalski ◴[17 Nov 24 14:51 UTC] No.42164459[source]▶
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?
replies(2): >>42169720 #>>42170875 #
6. LinXitoW ◴[17 Nov 24 21:47 UTC] No.42167612[source]▶
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?

replies(1): >>42170888 #
7. marcus_holmes ◴[18 Nov 24 04:29 UTC] No.42169720{3}[source]▶
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.

8. rob74 ◴[18 Nov 24 09:04 UTC] No.42170875{3}[source]▶
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?
9. rad_gruchalski ◴[18 Nov 24 09:07 UTC] No.42170888[source]▶
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.
10. jd3 ◴[22 Nov 24 02:10 UTC] No.42210541[source]▶
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...