Biggest Issue with D - Definition and Versioning

[Walter Bright]

On 1/17/2012 2:07 AM, Gour wrote:
> My example was just meant to show what might be the result when one
> feels that developers are not behind their product in a sense that one
> 'cannot count on the project' which was supposed to be continuation on
> my "we always get the feedback it's not safe investment of our time&
> energy and it would be better to use something else, either C(++), Java,
> Scala, Python etc."
>
> So, I highly admire the work of all members within D community giving
> something valuable for free, but being interested in success of D, I
> wanted to share my experience I have when trying to advocate using of D
> for real (open-source) projects *today*.
>
> I'll try to be more sensitive next time...

I'm not taking issue with sensitivity, just that one is *less* likely to get 
responsive bug fixes from Major Software Vendor, and so dismissing D for that 
reason is invalid.

I've seen people say "D doesn't have feature X, so I'm going to use language B." 
But B doesn't have feature X, either. Again, the reason given is invalid.

The real issue is something they're not telling you. The trick is finding out 
the real issue, which can take some insight. Otherwise, you'll waste a lot of 
effort chasing rainbows.

Sometimes, the real issue is "nobody ever got fired for buying IBM." You could 
fix every issue on their list, and you still won't close the deal, because you 
are not IBM. You cannot please everyone, it's better to recognize who you *can* 
close the deal with (there's always someone who is not impressed by IBM), and 
work on their issues rather than the rainbows and smokescreens.

That means focus on what we are good at.