Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 06-Mar-2016 10:21, Shammah Chancellor wrote:
> On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
[snip]
> Here's some stuff D shares with Go:
>
> "Single" binary deployments.
> Garbage Collector
> In-language slices and maps
> Foreach (Although D is much more powerful here)
>
> Some things D is weak on:
> * The name -- all I ever hear are penis jokes.

Thankfully not in my country ;)

> * Garbage Collector (!)

This is indeed a sore spot, Go rapidly advanced their GC and even took 
advantage of it being non-copying to deliver on lower-latency front. 
Wonder if we could squeeze some more bang out of GC.

> * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I
> understand they will be much more difficult to get to parity due to the
> feature set of D)

Strangely people love single imposed code style of Go, and in many ways 
other enforced conventions.

> * Docs  -- although these have gotten much much better recently -- the
> current implementation of concepts makes it hard for people to know
> where and when they can use a type.  E.g sort docs
> (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know
> what types of things I can sort as a newcomer? Even if I figure out that
> I need to look at isForwardRange, the docs there aren't terribly helpful
> either
> (https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I
> would put up a PR, but I don't know how to fix it without introducing a
> language structure for Concepts -- but this has been veto'd for a
> variety of reasons (primarily type explosion as I understand the arguments)
> * Libraries

Probably the biggest issue. Another one I'd pull is complexity, there is 
sooo many moving parts in D by now that we consistently fail to deliver 
a feature complete spec and/or compiler for it.

>
> Some things D is much better on (and would cause me to choose it every
> time and just contribute fixes where I could to the external tools):
>
> * Package management/build tools
> * Integration with existing build systems/libraries
> * Reusable algorithms that are FAST
> * Empowering programmer expressiveness without enabling magic

Overall my impression is that if we were to compare D and Go as tools, D 
would be more of meta tool - i.e. a tool to create tools whereas Go is 
ready made toolkit that is nicely crafted but quite limited.

Now I only need to appeal to the former somehow ;)

> -S.


-- 
Dmitry Olshansky