Go and generic programming on reddit, also touches on D

[Peter Alexander]

On 18/09/11 6:55 PM, Timon Gehr wrote:
> On 09/18/2011 07:16 PM, Peter Alexander wrote:
>> On 18/09/11 5:08 PM, Timon Gehr wrote:
>>> On 09/18/2011 03:48 AM, Andrei Alexandrescu wrote:
>>>> Quite interesting.
>>>>
>>>> http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> 2 hours ago, Andrei Alexandrescu wrote:
>>> > The problem is, Vector was just an example of a multitude of
>>> containers. The huge problem with slices is dogfood-related - they are >
>>> "magic" because the language features proposed to programmers were not
>>> enough for expressing a simple abstraction. Reserving "special" features
>>> for the language is a terrible way to go about programming language
>>> design.
>>>
>>> Don't D arrays do a similar thing? They are not templates, yet work with
>>> generic element types.
>>
>> Yes. As I understand, Andrei prefers things in libraries and Walter
>> prefers things built in to the compiler (obviously an
>> oversimplification, but I believe that's the general way they 'lean').
>>
>> There's advantages to both. Being implementable in a library means that
>> they can easily be swapped out or modified to work with other code, but
>> being built-in ("magic", as Andrei puts it) means that the compiler has
>> greater awareness of them and can do better optimizations, give better
>> errors etc.
>>
>> Of course, there are ways of extending the language to provide better
>> errors and allow better optimizations (e.g. 'pure' in D), but as a
>> purely practical matter, it's easier if they are just built-in.
>>
>
> Well, I think arrays should be built-in. What I was implying was that D,
> not entirely unlike Go, also has some magic. You can get almost the same
> with templates, so it is way better in that aspect than Go, but it is
> still there.

Yes, you are right. D does have some "magic". Every language has to draw 
a line between library code and built-in code. The only way a language 
can be purely library is if the "language" is just the source code for 
the compiler :-)


>>> Afaics, improving the language to the point were dynamic array-like
>>> structures could be implemented in the library without resulting in a
>>> bloated executable would be quite involved.
>>
>> I don't think you'd get much bloat in D by implementing dynamic arrays
>> with templates. Remember, the built-in arrays *are* mostly implemented
>> in D:
>> https://github.com/D-Programming-Language/druntime/tree/master/src/rt
>
> Those work like generics, not like templates. Making them templates
> would duplicate all the runtime functions that process arrays for every
> element type it is instantiated with. And I am sure that would add some
> bloat. D has no generics, just templates. But built-in arrays work like
> generics.

Yeah, they use runtime polymorphism like generics instead of compile 
time polymorphism.

I don't believe there's any way round this -- you can't solve it with a 
better language design. If you want to handle different types with a 
single interface then either you need to generate code for each type 
(templates) or use runtime polymorphism (generics). Of course, you can 
improve both to minimize the overhead, but there's a fundamental memory 
v.s. performance compromise.