On Wed, Dec 30, 2020 at 3:09 PM Jesper Louis Andersen <jesper.louis.ander...@gmail.com> wrote:
> Almost. It requires me to cast, so I'm wrapping it in a set of functions > which makes that cast. With generics, I can get rid of that boilerplate. (Casting? Method receivers have static types.) So some use cases boil down to having to write a dozen or half lines of code vs following the popular 25% vote and shifting Go towards where so many happily escaped from. Don't get me wrong. No doubt there are use cases which cannot be solved reasonably without generics. No doubt there are many other cases where generics will be an elegant and still readable solution either. I'm just not convinced that there will _not_ be a ton of bad code, bad because abusing generics, floating around in the future which I will have to read/cope with, if I would want to still use Go for 99% of my tasks at that point. FTR: Popular vote also demands exceptions or hidden execution control for errors, operator overloading and other things that IMO Go avoided intentionally. Because there's no good reason to have just yet another Java/C++/you-name-it programming language. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-V2N3Y_nqE%2BuB_KbVCW5-R3%2B4W3iz2F6wnVdOBmZsJ2BQ%40mail.gmail.com.
