A few notes on choosing between Go and D for a quick project

[weaselcat via Digitalmars-d]

On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
> On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
>> On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
>>> On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
>>>> On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven 
>>>> wrote:
>>>>> On 17/03/2015 10:31, Almighty Bob wrote:
>>>>>> It's far more useful for csvReader to return a type I know 
>>>>>> and
>>>>>> can use than it is to obscure the return type for the sake 
>>>>>> of
>>>>>> some philosophical ideal of increasing encapsulation.
>>>>>
>>>>> Part of the art of API design is to hide implementation 
>>>>> where it's not necessarily needed. Designers might err on 
>>>>> the side of hiding things, because how you expose something 
>>>>> is important as it has to be maintained indefinitely. If 
>>>>> they expose everything then the internals can never be 
>>>>> redesigned for better performance, etc.
>>>>
>>>> They don't increase encapsulation. The public members of a 
>>>> voldomort type are still public, you still have to code to 
>>>> the API of the return type whether it's a regular or 
>>>> voldomort type. You can keep as much private or public in 
>>>> either case as you like.
>>>>
>>>> All they do take the typename out of circulation, they make 
>>>> life harder for the user. There's no benefit. None.
>>>>
>>>> But at least the library author can stroke his chin a feel 
>>>> smug that there's one less type in the modules' namespace.
>>>
>>> Totally missing the point. The crux of the matter is this: 
>>> changing a voldemort type (assuming the public semantics are 
>>> the same) is not a breaking API change, because no-one else's 
>>> code ever names it.
>>
>> Seriously? You cant have a public API and private 
>> implementation with a regular type? That's something specific 
>> to voldomort types?
>>
>> Ask yourself what exactly do voldomort types enable you to 
>> hide that cant be hidden with a regular type? Just one thing. 
>> Their name. As you said no one else can ever name the type.
>>
>> That is no benefit to me the user. No-one has been able to 
>> even describe a benefit. Walters article on Dr Dobbs doesn't 
>> describe a benefit. It "increases encapsulation" you all 
>> squawk.
>>
>> No it doesn't. The private bits are still private, the public 
>> bits are still public.
>>
>> All it does is complicate the user side.
>>
>> Its the emperor's new clothes.
>
> It's not possible to construct a voldemort type outside of the 
> function where it was declared, and you can't know what that 
> type is, just what the API is. You can force type deduction so 
> the type returned can be changed without breaking code, so long 
> as the API is the same. That's how it increases encapsulation.

voldemort types sort of feel like a hack to work around the lack 
of real compile-time interfaces(concepts,) the same thing IMO 
currently plaguing template constraints and honestly causes a lot 
of compiler errors to be confusing.

I believe a few major patches in phobos were related to removing 
constraints and rewriting them as static asserts for better error 
handling.

see:

http://forum.dlang.org/thread/jronroxajqkrqitxwzlj@forum.dlang.org