On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:
>
> 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{}.
>
Because it can also be implemented in other ways.
> In this sense, I don't see a performance downside for boxing generics
> compared to the current state of things.
>
As said... there is a performance upside for some other approaches.
> >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."
>
The builds being fast are necessary for many things, mainly iterating on
features, tests.
>
> >It would be slower than copy-paste and generated approaches.
>
> It wouldn't be slower than interface{}, right?
>
Yes.
>
> >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.
>
Copy-paste wouldn't remove generics used in the standard-library... i.e.
it's hard to avoid the compile-time overhead. I agree, it's possible, but
unlikely that anyone will do it.
>
> On Tue, Mar 28, 2017 at 12:28 AM, Egon <[email protected] <javascript:>>
> 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
>> [email protected] <javascript:>.
>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
