Article calls D "irrelevant"

[Indraj Gandham]

About the article:

> He called this new language B. It was fast, it was lean, and it was the first step towards modern programming.

B was not fast, it was an interpreted language due to severe memory 
constraints which were only alleviated with the jump from the PDP-7 to 
PDP-11. The intended purpose of B was to implement UNIX itself, but this 
failed to materialise due to the slow performance.

It's probably also a stretch to call B "modern", because it was not a 
high-level language in the way we tend to think about the term today. 
The design decisions underpinning B are skewed heavily in favour of the 
compiler-writer rather than programmer convenience.[1] As far as I am 
aware, Thompson's experiences with PL/I were a significant factor in 
these decisions.

> His innovation was the introduction of a Type System. He created the char type for characters and int type for integers. Now the programmer could tell the computer that this box is for a single letter, so don't waste extra space on it.
This explanation ignores the fact that the PDP-11 introduced a 
floating-point arithmetic unit, which a typeless language would struggle 
to make use of.

> But, despite its achievement, D faced a classic problem. By the time D arrived, the world had already moved on. Enterprise companies were using Java and C#, and the world was still firmly locked into C and C++. A few years later, a language called Rust appeared which focused heavily on memory safety (the same principle as D), and it managed to capture the attention of the tech world in a way that D never quite managed — and effectively made D irrelevant.

Rust is not a replacement for D. It is not even a replacement for C++. 
It is a language that encourages poor engineering practices through 
authoritarian compiler features.[2] The only reason it has succeeded at 
all is due to intense lobbying. If you want to encourage D adoption at 
the enterprise level, you have to pitch it to decision-makers, not HN.

In response to this thread:

--> Paulo Pinto:

> Many of the features that D had, are now available in various flavours in Java, C#, F#, C++,  Swift doesn't matter if they are clunky or half way there versus what D has, they have the IDEs, libraries and frameworks to make up for it, and company overlords to push them no matter what.

As far as I can tell, IDEs have not solved all the problems that have 
arisen as a result of lacklustre execution of language features. C++ is 
a prime example, and fixing those errors is at least part of D's raison 
d'être.

In terms of libraries, D has access to the entire C ecosystem, which 
eclipses that of virtually every other language.

> Finally there is the whole AI programming, that to some extent makes the actual programming language irrelevant, where classical programming languages become a target for code generation out of human language or formal proofs.

See: https://machinelearning.apple.com/research/illusion-of-thinking
Credit to Adam Wilson for showing me this.

> However, it is what it is after all these years.

It is a mature, stable language that is officially shipped on major 
Linux distributions and ready for production use today. That is more 
than can be said for some of those other "hyped" languages.

--> Mike Parker:

> That said, in the absences of funding to hire a pro marketing team, the answer to this now is the same as it has always been: if you're using D and would like to see more people using it, tell the world about it. Write blog posts and post videos on YouTube. Give talks at tech conferences. Talk about your projects, the problems you've solved and how, the things you can do with D that are frustrating in other languages, and so on.

Yes, I think this is the way forward. Last year I gave a talk at a local 
cybersecurity event about how D's design can improve memory safety 
outcomes for systems programming without sacrificing developer 
ergonomics. I hope that some in the audience went on to try out D for 
their own projects.

> Right. Some people have gotten lucky getting it into their workplaces to one degree or another, but that's notoriously difficult. Worth trying, but don't expect much. 

> But there are plenty of people out there who are either open to or actively looking for something new. All it takes is one blog post or one video to pique their curiosity. Most of them will check it out and leave, but some percentage will stay.

I discovered D at the same time that I was thinking about rewriting some 
program we were using at work. I'd written the original version in Go, 
but I didn't like that language very much, so I was open to trying 
something else.

--> Dejan Lekic:

> Every "relevant" language was "irrelevant" first, until it became "relevant" (and back)...

Indeed!

--> Kapendev:

> If someone doesn't see value in D, then that is fine.
> Why should I care? 

For solo projects it doesn't matter, but there are times when you may 
need to convince your teammates or your boss. Some people also just like 
sharing knowledge and advocating for positions they feel strongly about.

--> Serg Gini:

> I think we should define "niche lang" better. As being non-popular doesn't make the language automatically "niche". Being "elegant" shouldn't be a niche.

Absolutely!

--> H. S. Teoh:

> I will never understand why some people are so insecure
> that their evaluation of things depends on others' acceptance of them.

I suspect it is down to lazy groupthink more than anything else. In any 
case, it is incredibly sad.

> In the meantime, D has been one of the best things that's ever happened
> to me.

Same here. I have specific ideas about how I want to program, and D 
allows me to express them in a natural way. Although I originally sought 
to replace Go, it has replaced C in all my new projects too.

> It said to install Windows 2000 or better, so I installed Linux instead.

:-D

Indraj

Footnotes:

[1] Examples include array references decomposing into pointers, or the 
omission of nested procedures (which would have required activation 
records to contain a static link). FWIW, PL/I had composite arrays with 
bounds checking, as well the ability to add custom upper and lower 
bounds, as opposed to BCPL's offset model.

[2] Naturally, I am referring to RAII and borrow checking. Those in the 
know have been using arenas to simplify memory management since forever, 
and scope() takes care of the rest. A good malloc implementation might 
use arenas internally for the purpose of avoiding the heap fragmentation 
that comes with RAII, but it cannot know the inherent relationships 
between different objects in terms of lifetimes. That is the job of the 
programmer. The existence of the borrow checker perpetuates the use of 
RAII, allowing Rust programmers to ignore obvious insights.