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

[amber via Digitalmars-d]

On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
> On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
>> On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
>>
>> This discussion happens often when discussing C++'s or D's 
>> `auto`. It doesn't matter what the type is, what matters is in 
>> the interface.
>>
>> As for storing it:
>>
>> auto foo = voldemort();
>>
>> Oh, you meant in a struct?
>>
>> struct Foo(T) {
>>   T thingie;
>> }
>>
>> auto foo(T)(T thingie) {
>>    return Foo!T(thingie);
>> }
>>
>> auto f = foo(voldemort());
>>
>> Atila
>
> That proves my point cost for the user just so the library 
> designer can group his type inside the function that returns it.
>
> How many times is csvReader used vs how many times is it 
> written. It it's 100 to 1, that's 100 times the cost to the 
> user vs 1 x the cost to the library author.
>
> I cant help thinking it's like how when programmers first learn 
> about design patterns they start trying to make everything they 
> can into a ****ing singleton.

I have on a number of occasions wanted this:

struct S {
     Iota r; // ?? Would be nice, can it be done ??
}

if(something) {
     s.r = iota(10);
} else {
     s.r = iota(0, 10, 2);
}


As a new D user and relatively new to programming I've tried 
really hard to find a way to do this and given up. If it's 
possible I'd love to know!!

I did try the template approach with "function return type part 
of my struct type" route but it a) made my code very messy with 
templates everywhere even where I didn't want them and b) the 
compiler memory usage blew out to over 4Gb with 2.067 and I could 
not compile my project.

I had to take it all out again and in the end implemented my own 
iota with my original approach (as above). I'm not doing that 
again.


bye,
amber