A few notes on choosing between Go and D for a quick project
Laeeth Isharc via Digitalmars-d
digitalmars-d at puremagic.com
Sat Mar 14 20:26:00 PDT 2015
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,
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
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.
More information about the Digitalmars-d