On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via
Digitalmars-d wrote:
I have followed the recent discussions about D and I can see
the usual
pattern, to wit GC, Go (or whatever) is so much better,
everyone
blaming each other for not contributing, not being allowed to
contribute blah.
Well, this forum *is* for discussing ways of improving D, so it
shouldn't be surprising that we constantly find things to
nitpick about.
:-) It doesn't mean at all that D is lousy or the community is
bad, 'cos
if it were so, we wouldn't even be here to begin with. We're
here 'cos
we care, and we complain 'cos we care enough to want things to
improve.
First of all, I am in no position to criticize anyone who is
contributing to the language. I don't contribute, because I
don't have
the time to do so. Indeed I have huge, massive respect for
everyone
who contributes to D. The only thing I do is to actually use
the
language and tell everyone about it. I have developed a
screen reader
plug in in D (using C libraries) that was ridiculously easy to
integrate on Windows as a DLL. I used vibe.d to create a
lightning
fast online version of the screen reader. Believe me, D's
supposed
sluggishness as regards GC is not so important for most
applications.
I dare say 90% of all applications are fine with the current
GC. I
compiled both applications with dmd (testing phase) not with
ldc or
gdc and they are very fast.
I agree. I'm still convinced that GC phobia is blown out of
proportion
-- I used to be in that camp, so I totally sympathize with
where they're
coming from -- but as you say, only a small percentage of
applications
actually need to squeeze every last cycle out of the CPU such
that the
GC actually starts to make a significant difference in
performance. Most
applications work just fine with the GC, and in fact, I'd argue
that
they work *better* with the GC, because manual memory
management is
*hard* (just look at how many security exploits are caused by
memory
management mistakes) and tedious (look at how often the same
memory bugs
are repeated over and over). GC-supported code is cleaner to
read,
easier to write, and in many cases, the simpler design of the
code
reduces the likelihood of bugs and eliminates a whole class of
bugs.
Sure you pay for that by short pauses every now and then, but
seriously,
90% of applications don't even *care* about such pauses.
For applications with slightly higher performance demands, gdc
-O3 (or
whatever the LDC equivalent is) generally improves performance
by about
20% or so above dmd. In my own compute-intensive projects, I
have
consistently noted about a 20-30% performance improvement when
compiling
with gdc, compared to dmd. That's pretty significant, because
GC pauses
are generally nowhere near that percentage, so just by
recompiling with
gdc already eliminates the perceived GC performance issue for
95% of
applications. Besides, avoiding frequent small allocations also
reduces
most of the workload of the GC, so you can still get pretty far
without
totally turning it off.
So it's really only the remaining 5% of applications that
really,
absolutely, *have* to go GC-less (or control it very tightly).
They do
happen to have supporters of the rather vocal kind, so we tend
to hear
from them a lot more, but that by no means is representative of
the
grand scheme of things as far as the GC is concerned!
[...]
Let's first make a list of things that have been achieved with
D and
that are on a par with or even bettar than in other languages
(C, C++,
C#, Go, Rust ...).
I don't know C#, Go, or Rust, so I can't really say much on
that front,
but at least as far as C/C++ are concerned, D totally beats
them flat in
the following points IMO:
- Metaprogramming. Templates in C++ scarred many for life.
Templates in
D are actually a pleasure to use.
- CTFE. Coupled with metaprogramming, this is a total killer
combination
that I've yet to see another language beat.
- Slices. Finally, a systems-level language whose string
support isn't
crippled (C), maimed (C++), or otherwise handicapped (Java).
And this
extends to arrays in general. While there *are* other
language with
nice string/array manipulation support, D is the only one I
know of
that does it without sacrificing performance.
- Ranges. It can totally revolutionize the way you approach
programming.
And, with metaprogramming/CTFE, they can still perform as
fast as
non-range-based code. Total win!
- Extended meaning of purity: IMO it's a total stroke of genius
to
define "weak purity" that allows you to implement pure
functions (in
the Haskell sense) using mutating primitives (loops and
assignments,
etc.). While the current compilers don't really do that much
with this
presently, there is a lot of potential here that may turn
this into a
killer feature.
- Built-in unittests. Sounds trivial, but I can testify to its
value in
dramatically improving the quality of my code. I've worked
with large
C/C++ codebases, and most of them don't even bother with any
kind of
unit testing -- it's up to the programmer to test everything,
and we
just take his word for it -- and simply accept the countless
stream of
bugs that come thereafter as a fact of life. Of the rare few
that
actually do have tests, the tests are usually (1) outdated,
(2)
commented out 'cos nobody cares to update them, (3) ignored
by the
coders anyway 'cos they can't be bothered to switch to another
language in another framework just to write tests that nobody
will run
while having their hands tied behind their back. D's built-in
unittest
blocks is a total game changer in this area, in spite of its
simplicity (which some people have complained about).
- Along these lines, static assert totally rawkz. It
ensures, at
*compile-time*, that assumptions in your code haven't been
violated
by a careless code change, forcing the person who made the
change
to fix it (rather than introducing a possibly subtle error
that
will only be uncovered months down the road on the
customer's
production site).
- The fastest regex library known on the planet (thanks to,
guess what?
metaprogramming and CTFE!). I'm a regex aficionado, and this
is a
total big deal in my book.
- Built-in Unicode support. Compiler-level support for Unicode
is
something C/C++ sorely lacks, and that immediately puts them
in the
"legacy" category. LibICU is a nightmare to use. D, however,
lets you
treat Unicode directly in the language. (Full Unicode
compliance isn't
quite there yet, but we're getting pretty close.) Modern
languages
like Java/C# also have built-in Unicode support, so D is at
least on
par with them. C/C++ is definitely behind in this category,
though.
These are just language-level cool stuff. At a higher level, we
also
have:
- rdmd: run your D programs like scripts, yet with native
compiled
performance. Rawkage!
- Dustmite: a totally revolutionary tool IMO, that changes
finding
heisenbugs from an impossible game of chance to something that
actually has hope of being fixed within reasonable amounts of
time.
- vibe.d: I haven't used it myself, but from what I hear, it's
extremely
awesome.
I'm sure there are many other items that can be added, but this
should
be a good start. :)
T
Thanks. That's a nice list. This is what I was talking about, the
experience with D, what you can achieve with it and how it
compares with other languages. We need more of this. I have the
feeling sometimes that to an outsider D might look like an
eternally unfinished business. A nice playground for programmers,
but not for production, which is absolutely not true. The GC
issue is sometimes presented as "the language will stand or fall
with this". As you noted and which is also my experience, the GC
issue ain't that big. 90-95% of all applications can live with it.
