12 ms·
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 provid
by indulona 2y ago
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.
- kaba0 2y agoWell, generics are mostly meant for library code. Just because you don't need it, doesn't mean that code you use doesn't need it.
- throwaway63467 2y agoHonestly 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.
- vbezhenar 2y agoORM is anti-pattern and reducing boilerplate is bad.
- makapuf 2y agoI agree. The best language to handle data in a RDBMs is SQL, and in that case the best language to handle application logic is Go (or Kotlin, Python or whatever). So there must be some meeting point. Handling everything in Go is not optimal, and all in sql not always practical. So how to avoid redundant data description ? I often have structs in a model Go file that reflect queries I do, but that's not optimal since I tend to have to repeat what's in a query to the language and the query to struct gathering is often boilerplate. I also almost can reuse the info I need for a query for another query but leave some fields blank since they're not needed.. the approaches are not optimal. Maybe a codegen sql to result structs / gathering info ?
- bluesnews 2y agoCould you expand on this? I don't like ORM because in my experience you inevitably want full SQL features at some point but not sure if you have the same issues in mind or not
- vbezhenar 2y agoORM is for object-relation mapping. Go is not object-oriented language and OOP-patterns are not idiomatic Go, so using ORM for Go cannot be idiomatic. That's generic answer. As for more concrete points: 1. Mapping SQL response to maps/structs or mapping maps/structs to SQL parameters might be useful, but that's rather trivial functionality and probably doesn't qualify as ORM. Things get harder when we're talking about complex joins and structs with relationships, but still manageable. 2. Introducing intermediate language which is converted to SQL is bad. Inevitably it will have less features. It will stay in the way for query optimisations. It'll make things much less obvious, as you would need to understand not only SQL, but also the process of translating intermediate language to SQL. 3. Automatic caching is bad. Database has its own caching and if that's not enough, application can implement custom caching where it makes sense. In my opinion the only worthy database integration could be implemented with full language support. So far I only saw it with C# LINQ or with database-first languages (PL/SQL, etc). C# and Go are like on opposite spectrum of language design, so those who use Go probably should keep its approach by writing simple, verbose and obvious code.
- indulona 2y ago> Go is not object-oriented language That is most definitely not true. Go just uses composition instead of inheritance. Still OOP, just the data flow is reversed from bottom to the top.
- deleted 2y ago[deleted]
- nordsieck 2y ago>> Go is not object-oriented language > That is most definitely not true. I think at best, you could say that Go is a multi-paradigm language. It's possible to write Go in an object oriented style. It's also possible to write programs with no methods at all (although you'd probably have to call methods from the standard library). That's in contrast to a language like Java or Ruby where it's actually impossible to avoid creating objects.
- TheDong 2y ago> 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.
- bobnamob 2y agoNot 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"?
- rad_gruchalski 2y agoNot 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.
- bobnamob 2y agoYou 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
- rad_gruchalski 2y agoI 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.
- metaltyphoon 2y agoPerhaps 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.
- deleted 2y ago[deleted]
- indulona 2y agounderstandable. thee are always valid uses cases. although ORM in Go is not something that is widely used.
- the_gipsy 2y agogorm just takes a pointer of your type and does reflection magic. It's worse than generica, I agree, but you don't get []any.
- kgeist 2y agoJust checked, in my current project, the only place where I use generics is in a custom cache implementation. From my experience in C#, generics are mostly useful for implementing custom containers. It's nice to have a clean interface which doesn't force users to cast types from any.
- BlackFly 2y agoContainers are sort of the leading order use of generics: I put something in and want to statically get that type back (so no cast, still safe). Second use I usually find is when I have some structs with some behavior and some associated but parameterizable helper. In my case, differential equations together with guess initializers for those differential equations. You can certainly do it without generics, but then the initial guess can be the wrong shape if you copy paste and don't change the bits accordingly. The differential equation solver can then take equations that are parameterized by a solution type (varying in dimension, discretisation and variables) together with an initializer that produces an initial guess of that shape. Finally, when your language can do a bit of introspection on the type or the type may have static methods or you have type classes, you can use the generic to control the output. Basically, they are useful (like the article implies) when you want to statically enforce constraints. Some people prefer implicitly enforcing the constraint (if the code works the constraint is satisfied) or with tests (if the tests pass the constraint is satisfied). Other people prefer to have the constraints impossible to not satisfy.
- aljarry 2y ago> From my experience in C#, generics are mostly useful for implementing custom containers. That's my experience as well in C# - most of other usages of generics are painful to maintain in the long run. I've had most problems with code that joins generics with inheritance.
- neonsunset 2y agoC# generics are way more powerful than that when it comes to writing high-performance or just very, err, generic code. Generic constraints and static interface members are immensely useful - you can have a constraint that lets you write ‘T.Parse(text[2..8])’. They are far closer to Rust in some areas (definitely not in type inference sadly, but F# is a different story) than it seems. Of course if one declares that they are an expert in a dozen of languages, most of which have poorly expressive type systems, the final product will end up not taking advantage of having proper generics.
- tonyedgecombe 2y agoI sometimes wonder if they should have implemented generics. On the one hand you had a group of people using go as it was and presumably mostly happy with the lack of generics. On the other side you have people (like me) complaining about the lack of generics but who were unlikely to use the language once they were added. It's very subjective but my gut feeling is they probably didn't expand their community much by adding generics to the language.
- cherryteastain 2y agoI think a lot of the people who wanted generics wanted them more to be like C++ templates, with compile time duck typing. Go maintainers were unwilling to go that route because of complexity. However, as a result, any time I think "oh this looks like it could be made generic" I fall into a rabbit hole regarding what Go generics do and dont allow you to do and usually end up copy pasting code instead.
- wyufro 2y agoI think "oh this looks like it could be made generic" is the wrong time to convert to generics. You should convert when you reach the point "I wish I had that code but with this other type". Even then, sometimes interfaces are the right answer, rather than generics.
- deleted 2y ago[deleted]
- cherryteastain 2y agoI mostly agree, hence the > end up copy pasting code instead bit of my original comment
- vbezhenar 2y agoGeneric containers are needed in some cases. Using generic containers with interface{} is very slow and memory-intensive. Not a problem for small containers, but for big containers it's just not feasible, so you would need to either copy&paste huge chunks of code or generate code. Compared to those approaches, generic support is superior in every way, so it's needed. But creating STL on top of them is not the indended use-case.
- gregwebs 2y agoThere’s an existing ecosystem that already works with the constraints of not having generics. If you can write all your code with that, then you won’t need generic much. That ecosystem was created with the sweat of library authors, dealing with not having generics and also with users learning to deal with the limitations and avoid panics. Generics have been tremendously helpful for me and my team anytime we are not satisfied with the existing ecosystem and need to write our own library code. And as time goes on the libraries that everyone uses will be using generics more.
- marcus_holmes 2y agoThe libraries will, yes. But folks just using the libraries still won't need generics. If you know your concrete types, they're just not that useful. Even in home-grown libraries, I find generics to be a convenience rather than a necessity. It's useful to not have my library code so tightly coupled to my non-library code. But it does also come with a cost: every so often I have to check what the library actually does because being loosely coupled meant that iterations in the rest of the system didn't automatically have to involve the library, so the library code can get left behind.
- jppittma 2y agoThe most frequent use case I and my coworkers run into where we use them is when we want type covariance on a slice. I.e., when you want to write a function that take some slice of any type T that implements interface I, such that []T is a valid input instead of just explicitly []I.
- eweise 2y agohere you go. func Ptr[T any](v T) *T { return &v }
- Groxx 2y agoThat's kinda the point. Generics are mostly a library concern, improving end-user experience and performance. End-user creation of generic types is relatively rare, and you can use them in very simple ways and that's almost always good enough because you don't need them to be maximally correct, only good enough. For libraries (that adopt generics): yes they can be complicated. But using them is mostly zero-effort and gets rid of a ton of reflection.
- slimsag 2y agoUnfortunately not everyone shares that opinion of their restricted use-cases. I've seen ~100 line HTTP handler methods that are implemented using generics and then a bunch of type-specific parameters inevitably get added when the codepaths start to diverge and now you've got a giant spaghetti ball of generics to untangle, for what was originally just trying to deduplicate a few hundred lines of code.
- Groxx 2y agotbh I'll still take it over a similar Gordian knot with interfaces. At least you can tell the restrictions are met at compile time, rather than silently failing at runtime because you (and/or someone else in the past) didn't notice one edge case lodged somewhere surprising.
- peterldowns 2y agoMy most common use of generics is when testing — check out my library for typesafe test comparisons. I find it really useful because I like having readable helpers for asserting in tests, but I also want compiler errors if I refactor things. https://github.com/peterldowns/testy https://github.com/peterldowns/testy
- whateveracct 2y agothis is wild because i use parametric polymorphism by writing `forall` in basically every Haskell PR i do for work ever i think Go having a pretty bad implementation of parametric polymorphism (a programming concept from the 70s) is probably the root cause here