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

[rumbu via Digitalmars-d]

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.