Using D

[Remo 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

Great description! Even if I do not agree to everything 
especially C++ related :)

I think all this advantages should visible for everyone why is 
new to D!
For example here:

http://www.slant.co/topics/25/viewpoints/11/~what-is-the-best-programming-language-to-learn-first~d