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

[Laeeth Isharc via Digitalmars-d]

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
> On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote:
>> I see D attracting *really* good programmers, programmers 
>> from, let's say the 90-95th percentile in skill and talent in 
>> their field on average. By marketing to these programmers 
>> specifically -- that is, telling everyone that while D is for 
>> everyone, it is especially designed to give talented and 
>> experienced programmers the tools they need to get their work 
>> done -- even if you repel several programmers from, say, the 
>> 45th percentile or below in exchange for the brand loyalty of 
>> one from 92nd percentile or above, it's probably a winning 
>> strategy, because that one good programmer will get more done 
>> than all the rest combined.

Isn't that implicitly what D is (and it is a compliment that you 
do a good job of unfolding it).  I agree with the economic 
understanding, and with the strategy.
>
> Yep, this is what I meant by my Blackberry analogy earlier in 
> this thread.  Blackberry used to own the smartphone market, 
> when it was limited to professionals who emailed and texted a 
> lot.  When the market broadened to include everyone, they 
> decided to go the popular route and sell touch-screen phones 
> without physical keyboards like everyone else.  It was a 
> disaster, from which they're only recently recovering by 
> offering physical keyboards again.  I'm not saying it _had_ to 
> fail, only that RIM clearly didn't have what it took to succeed 
> there.
>
> Similarly, D's never going to do very well with programmers who 
> don't care about the efficiency of their code: simpler, slower 
> languages like python or ruby have that niche sewn up.  The 
> best we can do is point out that if you're already here for the 
> advanced features, it can also be used for scripting and the 
> like.  And of course, we should always strive to make things as 
> easy as we can for both small and large projects, including 
> better documentation.
>
> One day, the tide may turn towards native efficiency again, say 
> because of mobile or more people writing code that runs on 
> large server clusters, and D will be well-positioned to benefit 
> if and when that happens.

The future is here already, but just not evenly distributed 
(Gibson).  It hit Andrei's employer early, but I am not sure 
Facebook is an edge case of no relevance to mortals.

http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade

Data sets are exploding in size but the marginal dollar value 
commercially of every byte is collapsing
whilst the free lunch from Moore's Law is over.  That means you 
have to use a JIT or native code, and the latter is not going to 
be C++, Go, or Rust for uses within the enterprise that require 
rapid prototyping and iteration to help answer dynamic commercial 
questions.