On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote:
>
> >Because it can also be implemented in other ways.
>
> Do you mean interface{} can be implemented in other ways? I couldn't make
> out your meaning.
>
There are multiple ways of implementing "boxing generics" and
"interface{}". Implying it has same perf. characteristics as interface{},
implies the same implementation as interface{}.
>
> >As said... there is a performance upside for some other approaches.
>
> The other approaches have downsides, or at least generation does. Compared
> to using interface{} as is done now, boxing generics improves type safety
> and expressiveness and has no performance regression. That's a clear net
> win.
>
I meant other generics approaches (not alternatives).
Boxing generics adds complexity to the compiler, without solving some of
the problems that generics intends to solve.
Mainly, implementing highly performant data-structures would still require
code-generation/copy-paste.
And that is a pretty big downside.
>
> On Wednesday, March 29, 2017 at 9:18:01 PM UTC-7, Egon wrote:
>>
>> 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 <egon...@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...@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.
