A few notes on choosing between Go and D for a quick project
Laeeth Isharc via Digitalmars-d
digitalmars-d at puremagic.com
Mon Mar 16 05:49:07 PDT 2015
On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad
> On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote:
>> We invariably end up talking about language features and
>> syntax, as if D lost out against Go, because of feature X
>> being (or not being) there. We lose, because we fail to give
>> people that warm glow in their chests. The feeling of "now I
>> have something", which is basically what makes people go for
>> something. I felt like this about D when I first got to know
>> it, after a long period of being frustrated with every other
>> language. Although irrational, my intuition was that D would
>> offer me a lot, and it hasn't failed to do so. But this is,
>> because I was willing to make an effort. Many potential users
>> are either not willing to make an effort or they don't have
>> enough time. So we should make it as easy as possible for them.
> Makes a lot of sense. But…
>> As was said in a post earlier, the decision to go for language
>> X is often not 100% rational, but also based on subjective
>> positive feelings. To ignore this basic human fact, doesn't
>> help us. Having a great language with advanced features and
>> doing some "feel good" marketing are not mutually exclusive.
> This is true, but D's main problem isn't that people haven't
> come to D with high expectations of getting a better
> alternative to C++. The problem is that they came for emotional
> reasons and left for rational reasons.
This is an interesting assertion, and you have been around here
much longer than me. Of course the above must be generally true
of any language (since one develops a better sense for what it is
like by using it for a while), and I suppose it is also true that
people who stick with D stick for more informed reasons. Are
there reasons to be concerned that the right kind of people don't
stick with D, given that it is still maturing as a language, that
not everyone can use it at work, and that there are many options
available now, so a degree of churn is normal. A language will
be successful by starting with a very high appeal to a certain
group, rather than a modest appeal to everyone.
> They key is in understanding why people leave. Retention of the
> _target audience_ is more important than adoption rate.
Okay, but target audience is an emergent more than a centrally
planned property, although one can remove the obvious roadblocks
for certain important groups.
> It seems that many of those that stays with D either picked it
> for a hobby, or are not primarily programmers (I am not really
> sure why they pick D? Does not seem like a rational choice.),
> then a very small (and vocal) group use it for business.
I don't know if true without the data (is it worth trying a
questionnaire on the download page) but supposing it is true is
this surprising given it is not yet standard in the enterprise,
and most firms are conservative? Surely most languages get their
start in this way. It is a rational choice for people in this
camp because native code, and who wants to deal with C++. (And
I love C, but...)
> In my opinion you need to pick a target audience, and with the
> CTFE focus targeting professional system level programmers is
> the only thing that makes sense. D needs to deliver on all
> aspects that C++ is good at before it is marketable, or else it
> will stay a hobby language for professionals and others. That
> means matching C++ on stability too.
See Innovator's Dilemma and Peter Thiel's work. It needs to have
a monopoly of appeal to certain groups, and as it develops spread
out from there. I don't see the link between CTFE and systems
> If it is more work to implement smart pointers in D than in
> C++, then there are some fundamentally unacceptable limits in
> the core language. So it is not only marketing... D is not
> D needs a redesign to get away from lock-the-world GC without
> scars... A language redesign that cannot be done with "last
> minute patches of special casing hell".
I don't claim to understand the topic well enough, but it looks
to me like a relative resource question combined with a desire to
do things elegantly (which takes longer even though it is the
right way) not a fundamental design question.
> Over focusing on growing the user base by making tutorials,
> will only make changes harder, and it will attract the wrong
> kind of people that will ask for the non-system-level features
> making it even harder to improve the core language.
> Why grow the user base before the language is done? You end up
> with no target audience, a very fragmented user base and
> equally fragmented eco system. Fragmentation makes it harder to
> produce professional level things.
That's one reason saying "D hasn't gone anywhere, so it won't"
seems a misdiagnosis. It wouldn't have been possible/ the cost
would have been higher to move to D2 with a much larger installed
base (look at Python), and the language previously perhaps wasn't
ready for prime time. There is a lot of FUD from this talk of D
not being finished - it seems like it's more than finished enough
to do good work in many domains. I appreciate for realtime the
GC is a problem, but that surely isn't a majority of use cases
and can be worked around (viz Sociomantic). I almost was put off
by the complaining (which goes back a decade and is to be
expected where people really do care), but am glad I pressed
I am not sure what more non-system level users would ask for as
_language_ features, nor what would lead to fragmentation rather
than diversity in the user base. The forums will suffer in
signal:noise at some point, which is a natural cost of growth,
and this would need to be dealt with thoughtfully, but that is a
good kind of problem to have. I really don't see how tutorials
will hurt the language, because it will bring in more users with
resources, and that will also help in the longer run.
D cannot be centrally planned, so one must be careful in speaking
of target audience - especially when one cannot know in advance
about who will stumble across it and find it useful.
> It is also completely misguided to push D as a web dev
> platform. D is up against: Ruby, Python, Dart, node.js+angular,
> Java, Go etc in an environment where performance is mostly
> about networking, database/ORM integration and infrastructure
> AWS/Azure/Google... D is nowhere near being a plausible
> solution in this space, CTFE is essentially pointless in this
That covers a multitude of use cases, and I am not sure that
every one of these requires more of those things you mention than
are currently available. Ruppe uses it for web development, I
think. It seems rather defeatist to suggest that because one
lacks features in certain domains one should just not even try to
develop them, although I can understand the frustration.
More information about the Digitalmars-d