←back to thread

Constraints in Go

(bitfieldconsulting.com)
210 points gus_leonel | 1 comments | 17 Nov 24 08:44 UTC | HN request time: 0s | source
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 #
1. TheDong ◴[17 Nov 24 11:44 UTC] No.42163626[source]▶
> reducing boilerplate is bad

Programming is about building abstractions, abstractions are a way to reduce boilerplate.

Why do we need `func x(/* args / ) { / body */ }`, when you can just inline the function at each callsite and only have a single main function? Functions are simply a way to reduce boilerplate by deduplicating and naming code.

If 'reducing boilerplate is bad', then functions are bad, and practically any abstraction is bad.

In my opinion, "reducing boilerplate is bad in some scenarios where it leads to a worse abstraction than the boilerplate-ful code would lead to".

I think you have to evaluate those things on a case-by-case basis, and some ORMs make sense for some use-cases, where they provide a coherent abstraction that reduces boilerplate... and sometimes they reduce boilerplate, but lead to a poor abstraction which requires more code to fight around it.