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.
