Using D

[H. S. Teoh via Digitalmars-d]

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

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice