About whether D / rust / golang can be popular.
laszloszeremi at outlook.com
Thu Nov 26 23:54:37 UTC 2020
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:
> Whether a programming language can be popular depends on what?
> I think there are two important points, that is, killing skills
> and availability. At the same time pay attention to
> I'll talk about my opinion today.
> ## D
> Must kill skill: It looks good?
It has four main advantages:
- Metaprogramming. In C/C++ you're limited to what the
precompiler can do, but D's metaprogramming capabilities are
almost other worldly, save for a few small stuff. D currently
doesn't have metaprogramming support for attributes, which could
solve the issue of attribute hell, especially with containers.
- Fast compile times with the performance of C/C++. Even with DMD
and using the GC, it not only outclasses most scripting
languages, but while compiling faster than C/C++. Once someone
takes the time to optimize the D code by reducing GC use and
using some compiler that has better optimization like LDC, it
becomes nearly indistinguishable from C/C++. This, alongside its
super-easy interoperability with other languages, makes the
language a good candidate for a low-level scripting language.
- Interoperability. It's mostly binary compatible with C and C++,
almost seamlessly can load their libraries, etc. I don't know
what's the current state of D's DLL support, if anything this is
a point where it must get better. D's main advantage should be
either integration into other projects, or integrating
preexisting ones into a D project.
- Multiple supported paradigms. Single paradigm programming is a
pitfall, which leads to forcing the same solution to every
problem, which in turn will lead to over-complicated codes, like
how "enterprise" devs often do object orientation on everything.
While functional programming is very promising, in itself can't
solve all the programming problems, and can lead to performance
issues from frequent data copying.
> Availability: standard library is poor.
It actually starts to get better, and since the language easily
interoperates with others, anybody can port C or C++ headers to
D. My current gripe is the mediocre XML support currently on D.
The current one in the standard library
> Bad IDE.
It's okayish, but there's a lot of potential to growth.
- For the code-d team: Do something about the lack of refactoring
support! It's super annoying to rename each thing individually,
since VSCode's "change all" feature is too overboard and only
works within a single file.
- For the Visual-D team: Please, add some integrated dub support!
It's the default package manager of D, and without it you're
destined to deal with dependency hell.
Due to the sheer power of the metaprogramming feature, any IDE
plugin must at one point integrate the DMD frontend. That's
probably the only way to get the whole metaprogramming fully
cooperating with IDEs.
> GC efficiency is low.
Not anymore, as the GC is now multi-threaded. `@nogc` and
`nothrow` attributes are must haves at functions that are
time-critical and where they're applicable. Reducing memory
allocations is a good practice, no `malloc` will speed up your
application if you need to allocate memory thousands of times in
a short time, while you could work on the same preallocated
> Lack of friendly debugging tracking tools.
Visual Studio works well as a debugger, but memory access
violations are a bit hard to trace down sometimes. Breakpoints do
> Lack of pprof and other practical tools.
It is in a dire need of a GUI editing tool, but I've made one for
my own graphics engine. I'm planning on making another one, might
be a VSCode plugin, if not it'll be a standalone app. That will
be a pretty big breakthrough, however I don't know yet what GUI
framework should I target. Maybe I can even add D export
functions to a preexisting one.
> ## Summary
> D language must improve usability if it is to become popular!
D must become even stronger in fields it's already strong, and
the community must fix the stuff where it's currently weaker.
I've outsourced many of the components of my game engine to
external libraries, both to allow easier unit testing (which
ultimately killed the integrated collections - it was quite
difficult) and to allow others to use them. Currently most of D's
issues can be traced back to a weaker community, but this is
More information about the Digitalmars-d