Egon:
>See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-
HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
I don't see the Implicit Boxing section point out that this is what happens
now when you shoehorn everything into interface{}. In this sense, I don't
see a performance downside for boxing generics compared to the current
state of things.
>You can also use copy-paste, code-generation.
I was referring to the downsides of copy/paste here: "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."
>It would be slower than copy-paste and generated approaches.
It wouldn't be slower than interface{}, right?
>When generics are added, then they will be (almost) impossible to avoid.
So the opt-in "slow builds" isn't really opt-in unless you really try...
By opt-in, I meant the code we write ourselves. In shared code, it would be
no more impossible to avoid generics than interface{} is now, which doesn't
seem to have been a problem. If there's a case where the performance is too
slow, one could always copy/paste the code and remove the generics from it.
On Tue, Mar 28, 2017 at 12:28 AM, Egon <egonel...@gmail.com> wrote:
> On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote:
>>
>> Something I've never seen addressed in the generics tradeoffs debate (not
>> saying it hasn't been, but I haven't see it personally)
>>
>
> See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-
> HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>
> is that without generics, you're forced to use interface{}
>>
>
> You can also use copy-paste, code-generation.
>
>
>> 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:
>>
>
> It would be slower than copy-paste and generated approaches.
>
>
>> 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,
>>
>
> When generics are added, then they will be (almost) impossible to avoid.
> So the opt-in "slow builds" isn't really opt-in unless you really try...
>
>
>> 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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/VbWfF865C3s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
