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

[bearophile via Digitalmars-d]

CraigDillabaugh:

> You said that "Unfortunately" this thinking is going out of 
> style "for good reasons".   I am confused (sorry, I am at work, 
> and didn't have time to watch the 1+ hour video you linked to -

I said "unfortunately" because it's another reason for us to 
refactor and change our coding habits :-)



> maybe some clues were there)!

Of course.


> I often find myself feeling a bit like Elazar.  Not long ago I 
> wrote some Python code using a bunch of the functional style 
> programming tools and I was very please with the very concise 
> code I had generated.  Then, I had to make some modifications 
> to the code. It took me an inordinate amount of time just to 
> figure out what the code was doing, and I had written it myself 
> just a few days earlier!

There's not a single correct answer to this. Replacing long 
bug-prone explicit-loops code with pre-made safer algorithms is 
often a good idea. The effort of learning some very generic and 
reusable functions is usually worth it. But I've also seen plenty 
of Haskell code that requires you to know tens of tiny functions, 
often named with symbols like !<>!. This is worse than writing 
for loops. High level constructs in D are often slower than 
low-level code, so in some cases you don't want to use them.

So as usually you have to choose wisely, because most solutions 
aren't perfect if you use them everywhere, there are many ways to 
write bad code if you don't keep your eyes and brain switched on.

Bye,
bearophile