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

[Laeeth Isharc via Digitalmars-d]

Hi.

Some points I think are important follow.  I can't do much on 
these myself for now as computer use limited by a spinal injury.

1. Compilation speed of D under reference compiler compares very 
favourably to most (all?) other compiled languages.  This 
facilitates rapid iteration, which works nicely with the 
'plasticity' of D code.  This should be emphasized on the landing 
page, and there should be a few standardised concrete reference 
points since for better or for worse modern people don't take you 
seriously if you don't quantify it.

2. D is a very powerful language whose essential features are 
easy to learn.  Coming from C, and not having written a great 
deal of code since about twenty years ago, it took me a few 
months to be productive in D (about the same as python, which I 
learnt shortly before D).  The generics and metaprogramming are 
not so straightforward, but you don't need to use them to be 
productive very quickly.  We should emphasize D can be a native 
code python (but is more than this if that is what you need)

3. I have said so before (the GroupBy docs) - standard library 
documentation is 'perfectly clear' if you have a technical 
mindset and are used to reading formalisms, but it is 
horrendously intimidating if not (which applies to many people).  
We need more examples, and they should put the use in context 
rather than just being tiny fragments - ie show how to do 
something useful with the function (cf python docs).  There 
should also be a guide to functions writing from point of what 
one wants to achieve.  toLower in std.string, but I need to go to 
std.ascii for doing the same thing to a character.  Eminently 
logical, but not obvious if you don't know where to look.

4. Need a better guide to libraries and frameworks oriented to 
how to accomplish common tasks.  (I really don't see why you 
wouldn't bundle vibed with dmd+phobos since small frictions have 
large consequences when you are starting out).

5. Different channels for tutorials organized by use case 
(accessible from front page not sidebar) - writing a server, 
writing a script, pulling data from the Fed website and charting 
it, simple gui app, simple database app.  Take cybershadow's 
slides comparing nodejs code to vibed code.

6. More user stories accessible from front page and well 
organised.  Make it visual and personal.  Facebook (not just 
warp, but odbc, any other stories), Sociomantic, Adroll, Remedy, 
etc.

7. It doesn't make sense for D to 'concentrate on XYZ use case' 
(languages can't be centrally planned - which is not to say 
identifying impediments is not useful), and nor is it a problem 
that it 'hasn't gone anywhere' since 2001.  Things develop at 
their own pace, and periods of quiet building are often needed 
before breaking out into the next stage.  An overnight success is 
a long time indeed in the making.

8. Libraries are a rougher area.  RSS, XML, JSON, Redis, 
databases, MIME, IMAP, HDF5, etc - there are solutions, but 
nothing standard and no consistency in documentation.

9. Mobile seems important for future of the language but seems 
the effort of a small number of people.

10. Calling D a systems programming language makes me think I 
shouldn't use it for non-systems purposes.  That's no longer on 
the front page, but it is the next thing I see here: 
http://dlang.org/getstarted.html.  What proportion of newcomers 
to D want to use it for systems programming?

11. This week in D.  should there be a tour of useful frameworks 
from code.dlang?

12. a good part of Pandas style functionality is not so hard to 
do.  Vlad Levenfeld has written a framework that may be 
interesting here, but it is still under development.

13. charting?