I have been in the D community for a very long time. I have seen D successfully deployed in companies, and the pain points associated with it. I have seen D fails to catch on in companies and why that is has well.

Let me tell you, none of this has anything to do with feature D has or does not have. At large, D has more features than most languages.

D chasing the next feature like a crack addict chase his next dose. With the same level of success.

The main problem people face with D in the real world are almost exclusively of the implementation kind. The list is endless (and yes, there are many bugs reports about these things). I recently made a post about how the OOP implementation is extremely sub-par vs what people in OOP languages would expect. no change of the language required to fix. See here: https://forum.dlang.org/post/hteuczyclxajakrisxjd@forum.dlang.org

But if you are not convinced, here are a few more example of thing being implemented wrong or existing feature not working right:

• D runtime is unable to see thread started manually (for instance with pthread-create) leading to all kind of bizarre behavior.
• Template symbols are generated as weak, which prevents inlining (!).
• Pretty much no cross module inlining, making helper function absurdly costly.
• scope(success) generates exception handling code.
• D goes virtual by default for class methods, but LTO is unable to finalize (contrary to every other languages going virtual by default).
• The GC implementation is nowhere close to where it needs to be.
• in contracts are dynamically bound (and in the callee) instead of statically bounds and in the caller.

These are just simple thing that I have on top of my mind, but there are a ton more. I have seen some of the above cause projects to fail. None of them require any significant language change.

There is nothing features like string interpolations or named argument can bring to the table that could pay for the implementations problem of existing feature. The cost benefit analysis is just a big L for D: the fail to address the main pain points, while causing massive breakage in the tooling ecosystem (syntax highlighting support in 3rd party IDE, code formatter, etc...), and it cost real time and resource to upgrade these, or come at the cost of other quality of life stuff nullifying their benefit (for instance, the quality of syntax highlighting for D has degraded significantly in vim and sublime text over the past few years).

In addition, some recent D features, such as @nogc, has been a productivity disaster int he wild. While the impact might not be felt on smaller codebases, the infectious nature of the feature makes large codebase significantly harder the refactor than they used to be.

Each time we take steps in that direction, D becomes a harder sell.

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

FWIW: I anticipate named arguments significantly improving our code. Large parts of boilerplate's generated builders exist only due to D's lack of native named arguments.

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

Named arguments surely was a pretty useful feature, not for any function, but for one which D was missing that even C had:

struct A a;
a = (struct A){a: 50, b:100};

Before named arguments, you could only use that syntax if you were using in the same line of declaration:

///compiles
A a = {
   a: 50, b: 100
};

///Does not
A a;
a = {
  a: 50, b: 100
}

Right now, it is possible to achieve that in any place:

A a;
a = A(a: 50, b: 100);

To me, this was a big win already for making cleaner syntax code, specially inside configuration parts.

But I feel like obliged to completely agree with your position and also, am waiting for all the improvements you last commented on classes which looked like a big win with no code breakage.
Template inlining is fairly essential to D, specially because of the Range interface nature.

On Thursday, 11 January 2024 at 13:09:56 UTC, FeepingCreature wrote:

+1, same here for named arguments.
I will leave to Theo the the reply about syntax highlighting [Joking :-)]

I sympathise with your opinion, but it seems to me that one thing does not exclude polishing the harsh points of the language that you listed. BUT, polishing hard point involve long term contributors, and we are going back to the "mother of all the problems".

I would add also that I've the impression that the IDE tooling quality improved al lot since years ago, and it's gaining more attention lately, web-freak is doing a great job, and Prajwal is working on dfmt.

/P

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

D needs a global task list and arranges for people to execute it.
What D needs is organization, and it is a strong organization!

On Thursday, 11 January 2024 at 13:29:30 UTC, zjh wrote:

Just like a task scheduler, various tasks need to be arranged reasonably.

On Thursday, 11 January 2024 at 13:34:24 UTC, zjh wrote:

///compiles
A a = {
   a: 50, b: 100
};

Why can't we construct it directly like C++?

//C++ :
A a = {
   50,100
};

On Thursday, 11 January 2024 at 13:42:20 UTC, zjh wrote:

//C++ :
A a = {
   50,100
};

We already have the function call syntax instead:

A a = A(50, 100); //Does the same as C++ {} syntax

But this syntax is ugly and bad when you have a struct with 10+ members. This is where named arguments done a change for me.

Also, as Paolo said, one thing does not exclude the other by the way.

Disagree on that one:

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

Well this is working as intended and needed here in shared libs. Registering and deregistering threads endlessly in shared libraries cost time. druntime cannot be used in full everywhere so at least provide escape hatch. Either use Thread or register your thread to the druntime. The common misconception is that you could just register threads once in a shared library but in reality when the threads dies elsewhere the GC will scan memory that doesn't exist anymore.

On Thursday, 11 January 2024 at 13:09:56 UTC, FeepingCreature wrote:

I think it's the other way around

Also, we already have such arguments: structs :-)