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

[jack death via Digitalmars-d]

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
> I watched silently this discussion and turns out that it will 
> end - as always - in some obscure debate about some obscure 
> languages or more than obscure features.
>
> I take the risk to be blamed, but let me tell you that the  
> developer world does not spin around R, Python, Fortran, 
> Haskell and Go. These are nice languages for a bunch of *nix 
> nerds or very specialized engineers but their usage is very 
> limited. The battle now is between C/C++/C#/Objective C/Java. 
> Even the abominable Javascript has a larger user base that 
> these languages.
>
> Secondly, the same futile waste of energy is consumed in 
> debates about portability. 97% of desktop system, 
> believe-it-or-not, are using various flavours of Windows and 
> some of them OSX. 95% of mobile devices are built on top of 
> Androis/iOS. There is important *nix usage in the server OSes, 
> but the usual developer will not start his programming career 
> writing server applications.
>
> The third mistake in my opinion is that the same "bunch of 
> nerds" are making and documenting the standard library. What 
> the heck is levenshteinDistance? What about 
> largestPartialIntersectionWeighted? boyerMooreFinder? When the 
> usual developer will try to eagerly learn D, he will say: "My 
> place is not here, you must be some computer/mathematics genius 
> to learn this language".
>
> About built-in functionality: Let's say that I want to sort 
> some strings. After I am shocked enough to find out that D has 
> three types of string which in fact they are not strings but 
> some weird arrays of something called immutable(char), I'll 
> look at the sort function prototype:
>
> SortedRange!(Range, less) sort(alias less = "a < b", 
> SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if 
> ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || 
> hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
> hasAssignableElements!Range) && isRandomAccessRange!Range && 
> hasSlicing!Range && hasLength!Range);
>
> Do you like it? I'll be very scared to use this unreadable 
> brain damaging enumeration of characters. To sum things up, if 
> someone wants to sort some strings, one must already mastering:
> - templates;
> - eponymous templates;
> - alias declarations;
> - ranges;
> - enums;
> - traits;
> - dive enough into phobos to understand the meaning of another 
> 8 templates depending maybe on another 1676327672 templates.
>
> Now let's say my name is Hans and I live in Germany or my name 
> is Ali and I live in Turkey. Do you think that the sort 
> function above will meet my expectations? No, because, despite 
> the fact that sort function will sort anything I can imagine, 
> does not take into account the most used scenario: culture 
> sensitivity.
>
> You know, comparing strings with culture sensitivity is just 
> one call to an API function on Windows, but I suppose that that 
> "portability" obsession keeps phobos ignoring it. Let's say 
> that I am not so lazy to call that function: this function is 
> not declared in the so 1990ish std.c.windows, nor in the 
> corresponding lib. So, to use that bloody function, I have two 
> solutions: learn to use coffimplib or link it dynamically with 
> LoadLibrary/GetProcAddress. Fighting the lazyness, I'll find 
> that before using it, I must convert my string to UTF-16 and 
> eventually zero-terminate it.
>
> Another one: there is standard library support for complex 
> numbers. Who's using these complex numbers? But who's using 
> currencies? I bet that more people are using currencies then 
> complex numbers. Despite the evidence, D has no standard 
> support for them. We, mortals, are expecting that 1 / 10 is 0.1 
> not 0.1000000001 and we don't give a damn about the meaning of 
> 2 + 3i.
>
> So, IMHO, if you want to attract users, here is my list:
> - concentrate on most used OSes - Windows/OSX and Android/iOS.
> - don't write scary documentation;
> - offer standard functionality instead of the obscure one. It's 
> nice to have it, but the use case scenarios are rare.
> - a GUI will be nice. You know, that thing allowing the 
> developer to put a button and writing events... instead of the 
> sad black console used by nobody I know.
>
> As you can see, there is nothing wrong with the language 
> itself, but with the library.

+1000