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

[Walter Bright via Digitalmars-d]

On 3/13/2015 6:18 AM, Dicebot wrote:
> In my opinion it is better to focus on tempting users with D strong bits than
> oversell it by trying it compete in topics it has inherent disadvantage. There
> is not point in try to compete with Go on topic of simplicity - they have
> crippled the language tremendeously to get that simplicity. Simple D has no
> value - I would simply prefer Go instead of it as it has head start advantage in
> toolchain.
>
> Instead it is better to focus on explaining users that they don't want what they
> think they want, akin to that Bjarne quote. And don't be afraid to admit to
> certain users that D is not a best choice for them. It doesn't mean that such
> valuable feedback should be ignore - there is indeed a lot that can be improved
> in the learning curve. But trying to fight for user who makes choice with
> "trendy" and "simplicity" in mind is a battle lost from the very beginning.

Yup. There are fashions in language design, and if one is always chasing the 
fashion one will always be behind. We should be looking forward in anticipating 
future developments. I think D has done very well in this, such as array slicing 
which other languages are adopting. C++ is now adopting UFCS, too :-)

Having a "me too" language is not an easy way to sell it - especially in the 
panoply of free languages. People will default choose the original.

Much of Go's and Java's simplicity comes from having a garbage collector. As we 
all well know, there are limitations that come with that. Moving beyond a GC is 
not simple.


I strongly believe that one can write simple and effective code in D. 
Unfortunately, there seems to be a learning curve to writing simple and 
effective code. I find much of Phobos to be excessively complex. (Though Boost 
C++ takes the cake in being terrifically complex code.)