
How does D improve on C++17? - curtis
http://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?
======
sprw121
D is a awesome language to work with, it's got many useful language features
that make the activity of code writing a pleasure. - I hope this criticism is
taking constructively.

However not a beat a dead horse, but if you want to process more than a
trickle of data in it you run into problems with the GC really quickly. I
really feel the language would be better off without the GC.

These are not the same issues address by the JSON compiler post or w/e that
surfaces a couple months ago.

From what I can tell, theres a global lock around everything in the GC,
including allocations. In a multi-core world, this just simply doesn't work
and it one of the major pain point of the language. I write data-intensive
processing on high core count machines (32), and have had to resort to
0-allocation strategies, or in map-reduce contexts actually sharding at the
process level, writing the results to disk, and then running a reducer process
over the results.

You can write performant D code, but you give up large amounts of code safety.
It's essentially just whatever you'd write in C++ without the ownership
semantics it gives you.

You can't have a core part of your language being an essentially unavoidable
massive point of contention.

I've literally seen 20x or more speedups in multithreaded cases just by making
sure I reuse every buffer rather than create new ones.

I feel this is really holding back an otherwise great language to work in.

This is discussed in the reddit thread in more detail.

~~~
WalterBright
> I've literally seen 20x or more speedups in multithreaded cases just by
> making sure I reuse every buffer rather than create new ones.

Reuse rather than free and reallocate is a core practice whenever you feel the
need for speed, regardless of the memory allocate strategy used.

For some very fast D code:

[https://github.com/facebook/warp](https://github.com/facebook/warp)

Minimizing the amount of heap memory allocated is a core strategy.

~~~
sprw121
Thanks for responding. I've seen this code used an an example before actually.

Not that buffer reuse/avoiding heap allocations was unknown to me, it was just
surprising to see this in an application that spent most of it's time waiting
on the network.

I will say as a positive point that the equivalent D code to a C++
implementation was much cleaner due to build in array slicing among other
things.

There are other areas where heap allocations are not so avoidable however
(some hashmaps, some std's). My main point is that like at all languages, heap
allocations are slow, but here they bear an unnecessarily large contention
factor.

I really like D so I hope this is helpful feedback.

------
ridiculous_fish
> D has no need for a preprocessor

How does this work, specifically conditional compilation? I have lots of code
like this:

    
    
       #if __APPLE__
          /* do things the OS X way */
       #else
         /* do things the Linux way */
       #endif
    
    

Where the OS X way calls functions that do not exist on Linux, and vice-versa.
How does D handle this?

~~~
WalterBright
Check out [https://github.com/D-Programming-
Language/phobos/blob/master...](https://github.com/D-Programming-
Language/phobos/blob/master/std/file.d) at line 33 and on. You'll see: version
(Windows) { ... } etc. For the specification on how this works:

[http://dlang.org/version.html](http://dlang.org/version.html)

The salient point is that conditional compilation in D is not text based, it
is AST based. Furthermore, for 'static if', the conditional expression has
access to the full symbol table and power of the D language - it is not a
separate preprocessor language with its own rules and separate symbol table.

~~~
ridiculous_fish
Thank you for the reply. That's very elegant!

------
CyberDildonics
D is a fantastic language. C++ is so difficult to unseat as a systems language
now since it is back as a moving target which is both evolving and has
extremely robust tools to go with it. Challenging it on the language level is
not enough.

~~~
fsloth
Yeah. C++ has so good tooling that despite what new language I try, I always
hit some implementation, ecosystem or tooling issue that always leads me to
conclude I would have been more productive with C++. Which sucks monkeyballs
as aesthetics go.

------
giancarlostoro
I'm curious how many people out there on HN actully use D and what for? I
don't typically see D based projects here on HN so it would be interesting to
find out about any use cases where D was found a perfect fit.

~~~
maxerickson
WalterBright uses it in his compiler.

~~~
edmccard
>WalterBright uses it in his compiler.

Ironically, the dmd compiler is written in C++.

~~~
WalterBright
D didn't exist when the dmd compiler was written. But Daniel Murphy has
written a C++ to D converter, and it's looking like the next release will have
dmd written in D.

~~~
edmccard
>it's looking like the next release will have dmd written in D.

Is that going to make it trickier for GDC/LDC to stay in sync with DMD?
(Either way, it's exciting news!)

~~~
WalterBright
Tricky or not, they're on board with the jump.

~~~
henderson101
How will you then bootstrap it on new platforms? Will it become reliant on
cross compilation for bootstrap?

------
frankzinger
> D has a package manager. C++ has none that is popular in its community.
> Therefore, using a third-party library is many times easier.

This comes up all the time in reference to C++. C++ doesn't need a package
manager because it has excellent support from distro package managers. Most
libraries are in the system package manager. And yes, sometimes you need a
newer version of a package or one not quite widely-used enough to be in the
system package manager, in which case you need to do compile it yourself or
install it manually. But that is a problem common to all package managers and
there is nothing about D which will make it any easier.

~~~
p0nce
Almost every C++ codebase out there vendor all dependencies. Looks like they
are not using the system package manager. Windows has no package manager with
such library releases. Language package managers have problems, but they do
make the work easier.

Anyone here unhappy with pip?

~~~
frankzinger
> Almost every C++ codebase out there vendor all dependencies. Looks like they
> are not using the system package manager.

Yeah, e.g. Chromium. But that was also the reason why Fedora refused to
provide packages for Chromium. Distros don't like projects that include their
own versions of libraries because it goes against how things are supposed to
work (maintenance and, by implication, a security nightmare). I know that
there are many C++ projects in the various distro package repos, and no way do
'most of them' include their own copies of dependencies.

~~~
p0nce
In the closed source world I'd say most codebases are like Chromium (difficult
to say of course). It's a bit like distributing an application with binary
libraries and a no-go for security indeed.

~~~
frankzinger
Yeah I am sure it's very common in closed source or internal systems. One
place I worked at recently did that. All of my comments are about open source
systems such as Linux and BSD.

------
TheAceOfHearts
D looks like a really interesting language, I had never checked it out prior
to reading this. unittest blocks look like they'd be super helpful. And it has
modules, which I consider a must-have.

In what areas would D excel? What are its downsides? What did you like and
dislike the most? I'd be really interested in hearing about people's
experiences.

~~~
Profan
As a D programmer currently making a small game engine + networked rts game in
the language, invariant blocks are another thing I really enjoy about the
language:
[http://dlang.org/contracts.html#Invariants](http://dlang.org/contracts.html#Invariants)

Lets you specify contracts which are asserted on construction and destruction,
it's great.

The meta programming is also wonderful for things like serialization of data,
simply iterating over a type's members at compile-time to generate
serialization code, cutting out much bloated code. It's worth noting that it's
metaprogramming for humans, _compared_ to c++, but sometimes leaves a bit to
be desired documentation-wise, all the building blocks are there, but
sometimes you'd like to not need to reinvent the wheel every time you attempt
some metaprogramming-related task.

Things I don't enjoy include the core language's reliance on the GC, including
things like exceptions relying on GC allocations.

Thankfully they've made it a bit easier to track down things which may
allocate gc memory lately with accompanying flags to the compiler, which
prints a trace of where it may happen.

~~~
yoklov
I'm always on the look out for improvements to C++, and it's been a while
since I looked at D... Hope you don't mind if I ask you a couple questions.

Can you still turn off the GC? Lets say I don't like exceptions, and that I
don't mind implementing library code on my own, would turning GC off impact
anything else?

How is the story for deploying executables to mac/win/lin? Is it as easy as
C/C++?

Also, do you know if anybody's shipped high quality games with it before? It's
been a while now, I'd hope so, but I haven't heard of any. Pretty sure no AAA
games have used it but maybe some indie?

~~~
CyberShadow
> Can you still turn off the GC? Lets say I don't like exceptions, and that I
> don't mind implementing library code on my own, would turning GC off impact
> anything else?

You can turn off the GC in the sense that memory allocation will always
request more memory from the OS instead of occasionally starting a collect
cycle. However, you can alternatively use manual memory management
(malloc/free, allocators/RAII on top of that, etc.), which will never trigger
the GC.

> How is the story for deploying executables to mac/win/lin? Is it as easy as
> C/C++?

Yes. I think for Posix systems, you can optionally link dynamically to the
runtime/standard library.

> Also, do you know if anybody's shipped high quality games with it before?

IIRC, Remedy Games used D for engine scripting on XBox 360. Manu Evans talked
about this at DConf 2013.

Here's a commercial indie game written in D:
[http://www.inventivedingo.com/mayhemig](http://www.inventivedingo.com/mayhemig)

~~~
yoklov
Well, a couple things about it make me nervous, but CTFE and a not horribly
broken compilation model might make it worth trying out next weekend...

------
jA_cOp
I was working on a similar article just a couple of weeks ago for the D wiki,
but I wanted to focus on the really big things, and I want to include more
examples:

[http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article](http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article)

~~~
p0nce
Yeah, my article is a bit of a quickie and not very good, I didn't expect
people would post them here and on reddit. Moreover, it isn't a big picture
post.

------
iwwr
D looks great, but I feel like depending on a GC is kind of a deal-breaker. If
that is accurate, then D fills the same niches as Google's Go rather than
C++'s. Rust looks more like a proper replacement for C++.

~~~
f3llowtraveler
You can still "delete" by hand in D. The GC just does it if you fail to.

------
avinassh
Kinda related: Apple's blog post on how they borrowed an idea from D, about
assert statements:
[https://developer.apple.com/swift/blog/?id=15](https://developer.apple.com/swift/blog/?id=15)

------
pyabo
I use C++ but I don't really like it, but ... we need all the libraries that
exist in C++ rewritten in D. And also, the same compiler support in the
development frameworks. Otherwise, it will be a failure.

------
kruczek
> No more header files, today

> Even when C++ compilers implement modules and you can finally use them,
> headers will still survive alongside modules for backward compatibility.

Uh, that one is just weird. So, a reason to use D is because C++ can support
older projects?

------
ryanobjc
Is now the time for D? I really wonder, I am not really sure. Certainly a lot
of languages go thru a period of obscurity before success, but I'm still
uncertain.

The one issue that sticks for me was the dual standard libraries. Just seems
so messy.

~~~
WalterBright
The dual library issue ended 7 years ago or so.

~~~
ryanobjc
enh shows how much i know.

Honestly, I'm pretty excited for Rust. Having a strong proof of lifetime
enforced by compiler is very compelling idea.

