Pitching D to a gang of Gophers
Dmitry Olshansky via Digitalmars-d
digitalmars-d at puremagic.com
Sun Mar 6 06:02:25 PST 2016
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
More information about the Digitalmars-d
mailing list