←back to thread

Constraints in Go

(bitfieldconsulting.com)
210 points gus_leonel | 1 comments | | HN request time: 0s | source
Show context
indulona ◴[] 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 ◴[] 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 ◴[] No.42163242[source]
ORM is anti-pattern and reducing boilerplate is bad.
replies(5): >>42163314 #>>42163315 #>>42163626 #>>42163744 #>>42168321 #
bobnamob ◴[] 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 #
rad_gruchalski ◴[] 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 #
metaltyphoon ◴[] 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 #
rad_gruchalski ◴[] 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 #
1. rob74 ◴[] No.42170875{5}[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?