>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.
>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.
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.
