About whether D / rust / golang can be popular.

[solidstate1991]

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 
> shortcomings.
>
> 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 
memory location.

> 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 
work however.

> 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 
slowly changing.