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

[Laeeth Isharc via Digitalmars-d]

On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad 
wrote:
> 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 
level programming.

> 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 
> complete.
>
> 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 
ahead.

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 
> domain.

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.