Something I've never seen addressed in the generics tradeoffs debate (not
saying it hasn't been, but I haven't see it personally) is that without
generics, you're forced to use interface{}, which just boxes the values
anyway. So you're already paying a performance cost for type-agnostic code
without generics. And if you copy/paste code instead of boxing, you're just
bloating the size of the binary like generic templates would. It seems to
me if boxing generics was added, there wouldn't be a downside: if you
didn't want to pay the performance cost of boxing generics, then don't use
generics; if you can pay the cost, then use them, and it won't perform any
worse than it would now with interface{}, and perhaps could perform even
better, depending on the semantics and implementation. You could have the
same opt-in performance tax in the form of bloated binaries/slow builds as
well, but lack of an official debugger right now is predicated on builds
being fast, so that seems like a no-go.
On Friday, March 24, 2017 at 12:10:08 PM UTC-7, Mandolyte wrote:
>
> The recent survey reveled that generics was thing that would improve Go
> the most. But at 16%, the responses were rather spread out and only 1/3
> seemed to think that Go needed any improvement at all - see link #1. I
> think most will concede that generics would help development of algorithms,
> libraries, and frameworks. So in the spirit of friendly rivalry, here is a
> list of algorithms developed for Swift:
>
> https://github.com/raywenderlich/swift-algorithm-club
>
> As you might guess, it is chock-full of generics. Yeah, I'm a little
> envious. :-) enjoy...
>
>
>
> #1 https://blog.golang.org/survey2016-results
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
