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

[Paulo Pinto via Digitalmars-d]

On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote:
> 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.

Hence why both Java and .NET are getting full AOT compilation to 
native code on their canonical toolchains in Java 9/10 and .NET 
4.6.

--
Paulo