On Sat, Apr 1, 2017 at 12:11 AM, Egon Elbre <egonel...@gmail.com> wrote:
> On Sat, Apr 1, 2017 at 1:42 AM, Will Faught <will.fau...@gmail.com> wrote:
>
>>
>>> For example []GenericElement could be boxed as:
>>>
>>> struct{ itab ptr; ... data []struct{elem ptr} }
>>> or
>>> []struct{itab, elem ptr}
>>>
>>>
>> Can you explain in more detail what's going on there? What's itab? You
>> seem to have pointers represents the slice elements, and that's what I
>> meant by allocating on the heap and passing pointers around. Boxing is just
>> moving values from the stack to the heap, or starting a value in the heap
>> rather than the stack, right?
>>
>
> https://research.swtch.com/interfaces
>
> When you have a slice you could specify the interface table pointer once
> or for each element. One could prevents significant amount of memory at the
> cost of making internals more complicated.
>
> Boxing also involves adding additional type information to distinguish
> between different types of pointers.
>
>
Right, but my point is that currently it's not implemented that way, so it
works the same way, so there would be no performance regression.
>
>>
>>>
>>> https://www.infoq.com/presentations/java-evolution-performance
>>>
>>>
>>
>> Which part of that are you referring to?
>>
>>
> The 10x performance difference in dictionary implementation between C# and
> Java.
>
>
Sure, if you implement it the right way, you can do even better than pure
boxing, but (without having read your source or being familiar with what C#
does under the hood for its reified generics), but do they achieve that
with some tradeoff? Like compile-time or run-time specialization? I'm
talking about not having a tradeoff at all.
>
>
>> My original point was the relative upsides and downsides of boxing
>> generics relative to what Go is now, not boxing generics versus other kinds
>> of generics in an abstract sense. Constraints have already been made on
>> these tradeoffs, for instance fast builds. You seem to be talking about
>> general pros and cons for generics approaches and implementations. It'd be
>> great to start from scratch and ponder all these ideas, but I'm talking
>> about building on what we already have.
>>
>
> Yes.
>
> I think the reason boxing hasn't been implemented is because it doesn't
> improve the current Go language enough. You can already use interfaces as
> such boxes and implement small wrapper around them to make it type-safe...
>
>
Generics does improve the language, though, that's why generics is already
in the language to some degree with the built-in map, slice, array,
channel, etc. types, or the ability to require that both operands for the
==, +, etc. operators are the same type. Those features exhibit the type
safety and expressiveness benefits you get with generics. The Go authors
themselves have implicitly praised the virtues of generics by including it
in a limited form from the outset. An argument against generics is an
argument for slices, maps, channels, etc. only working on interface{}
types. Who wants that?
> Is something missing here?
>>
>
> Accidentally sent the email too early :D
>
> http://research.swtch.com/generic
>
> The reason Go doesn't have generics is because the designers of the
> language try to avoid all the problems listed, at least to some degree.
>
> Sure, you can disagree with this philosophy, which is fine, I completely
> understand. But, that is the route Go Team has chosen. The only way forward
> is to find newer more interesting trade-offs and implementations.
>
Agreed, fair enough, but my point was that, while the Go Team identifies
boxing as having a performance cost, it dosn't acknowledge that this cost
is no different than using interface{}, as you suggested above, which just
boxes the values anyway. If we're already going to be boxing values, we
might as well get some type safety and expressiveness out of the deal.
--
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.
