Using D

[Chris via Digitalmars-d]

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.