Pitching D to a gang of Gophers

cym13 via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 6 12:56:10 PST 2016


On Sunday, 6 March 2016 at 14:02:25 UTC, Dmitry Olshansky wrote:
> 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.

Just to temper some points that I agree with in principle:

>> * Garbage Collector (!)
D doesn't need a better GC in my opinion. Go's GC has to be 
really good because AFAIK there is no other way to manage memory. 
Same for Java. But as good as a GC can be it will never be good 
enough for all applications. D solved the problem by proposing 
other memory management schemes so when the GC isn't good enough 
you just don't use it. Developping such schemes is *way* more 
important to D's future than a better GC that can never be more 
than good enough for more people but never everybody.

>> * Libraries
There again as using C libraries in Go is tiresome there is more 
incentive not to reuse them. OK, this is a weak point, I too 
think this is maybe the most proeminent D flaw.


More information about the Digitalmars-d mailing list