
D’s Newfangled Name Mangling - ingve
https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/
======
vram22
I've used D some, for small command-line utilities. It has some good features.

For anyone who wants to get an idea of what D is like, there are example
programs on the dlang.org site. Rosetta Code will be another good site for
examples.

Also, some of my D programs are online here (a few of the posts are not about
D code per se, the others are):

[https://jugad2.blogspot.in/search/label/DLang](https://jugad2.blogspot.in/search/label/DLang)

------
mml
D is indeed interesting. Wrote some experimental code this fall, was fairly
happy with it, but wound up going w/ rust.

~~~
stochastic_monk
I feel like D would fight with Go in the realm of things I'd use it for, in
which case I'd pick it.

On the other hand, D supports a lot of great C++-style stuff, but I'd never
pick it in that regime because it'd be the same amount of effort without as-
fast-as-possible.

~~~
klickverbot
> it'd be the same amount of effort without as-fast-as-possible.

While the first part is perhaps somewhat subjective, the second is just wrong.
D allows you to get to the same bare-metal, no-holds-barred level of
performance that C++ does – I wonder where that misconception would come from.

Note that this is not just an academic possibility, but there are real-world
use(r)s of D in exactly that domain, for example the folks at Weka.IO for
their distributed file system. Of course, their sub-millisecond latencies
don't leave much room for careless use of the garbage collector. But being
careful about memory allocations for that sort of application is just as
sensible a thing to do in D as it is in C++.

------
imh
D seems like a cool language. Do many people use it?

~~~
maxxxxx
D is an interesting case study for good technology somehow not succeeding. The
people working on it are very good and it's a really interesting language. In
theory it should slowly have taken over from C++ but for whatever reason this
didn't happen.

~~~
ionforce
What are some prevailing opinions on why it did not succeed?

~~~
systems
I would strongly recommend you browse and maybe contribute in the Dlang forum
[https://forum.dlang.org/](https://forum.dlang.org/) , to build your own
opinion, the forum is very friendly and welcoming for beginners

Some of the prevailing opinions on why D didn't succeed

\- Garbage collection, D has a GC, and for a very long time it seem to have
been positioning itself as a C++ replacement, having a GC, seem to have hurt D
more than it benefited it, in this regard

\- D vs D2, the current Dlang is actually as I understand D2, moving to a new
version that is not fully backward compatible seem to have at least in the
past scared away some possible adopters, this seem to be no longer the case,
there is only one D now, and this might be a case when lack of popularity was
helpful

\- licensing issues, I really dont know much about this, but there was some
licensing issue surrounding the main D lang implementation DMD, which was also
resolved recently

The above 3 points, are what I would call the "prevailing opinions"

Two of them are now fully resolved and only the first one GC , is a work in
progress ... once its resolved, and it seems they are working on it ... there
will be no excuses

What I personally believe, after lurking in their forum for a while

\- D, doesnt have a good product owner, it lacks vision, and it have no
competitive advantage

\- Walter Bright and Andrei Alexandrescu, are super smart developers, but in
my humble opinion ... very bad Product Owners, and just to support my opinion,
before anyone gets angry at me ... we all agree D is not popular, so ... this
is just a statement of the obvious

\- Strategic advantage is a key word here, D have none, and again, the
Strategic is a key word here, even if some will list for you the advantages of
D, none of them is Strategic

With all I have said, dont let this stop from learning D, I do plan to learn
more of it, and while I don't see D taking over from C++, Go, OCaml or Python
... I think it might be a good tool for small teams, who don't want to be
fragmented across many languages

~~~
le-mark
To me it seems like there are three broad categories of applications one would
use D to implement; network services (ie servers), gui apps, and "other" such
as compilers or command line tools. IMO go has won for writing servers; it's
incredibly compelling, it has it all (except generics, as someone will surely
interject); crypto, ships with easy to use protocol impls (ie http, websocket,
etc). The gui lib story for D isn't clear to me at all. Are there bindings to
gkt or qt for example? Maybe someone can respond here about that. That leaves
"other" which, sure, D seems like a great option.

~~~
bachmeier
You forgot the one for which D is best suited: scientific/numerical computing.
It produces fast code, it is used by small teams/single developers, it
integrates well with C, and much of the work is interactive, requiring fast
compilation times.

~~~
stochastic_monk
I think part of the problem is that D isn't as good as Python for
scientific/numerical computing, and that people doing Python for it will
typically drop to C++ when they need that last boost.

~~~
bachmeier
> I think part of the problem is that D isn't as good as Python for
> scientific/numerical computing

I realize that some hold that opinion but I and many others don't.

> people doing Python for it will typically drop to C++

That's something you don't need to do if using D. It's also the biggest
selling point of Julia.

------
cryptonector
I don't understand why mangled symbol compression is needed. Sure, you need to
demangle it for debugging and such, but... all you need is a lookup table, and
then you can just hash them down. Yeah, then you need that extra metadata, but
with mangled symbols you have it anyways. Hashing + lookup seems much less
error prone.

~~~
klickverbot
There are some advantages to having access to a human-readable representation
for the symbol name, for example because not every piece of binary tooling out
there necessarily also supports reading debug info for the target platform in
question.

However, another benefit of this is simply that even if you can hash a huge
string down to a fixed length, you still need to construct your huge string in
the first place during compilation.

With D generally being quick to compile, by the time your symbol names were in
the megabytes, all the string creation and manipulation could take up an
appreciable fraction of the total compile time. (No kidding – I was quite
surprised to see this show up on the profiles as well.)

