What's the standard use-case for D 'in the wild'? It looks interesting and is one of the few languages I've heard of but haven't used -- might try it out on my next project :)

Probably the reason D never got much attention is that D seems too much like C++, similarly to the way that C# is much like Java. (C# has the full weight of MS behind it, which D never had; yet, C# has not displaced Java.)

D works for basically the same set of problems as C++, in much the same way. D, not bound by history ("mistakes", you could say) could be simpler than C++, and able to do some things more neatly, but not enough so to match C++'s momentum—also a product of history. Since D came out, C++ has evolved in ways hard to keep up with. Some make it more like D, but those don't help D.

Rust is different enough from C++ to have some hope of carving out its own space, while trying to address the same sort of problems C++ does. Rust also abandons history, with consequences like D. However, Rust is developing its own complexities. In the end, if it survives, Rust and Rust code will be fully as complex as C++ and C++ code, just off in a slightly different direction.

But it is too early to know whether Rust too will, in the end, fail to find a mainstream place. Ada and Pascal both once had far wider use than Rust, and faded. Ultimately, C++ can do anything Rust can, has capabilities Rust is not expected ever to match, and is still evolving fast. So, for anything that might need to be maintained by somebody else someday, it is easier to believe that a C++ programmer could be found to do it.

In the end, the only true determiner of whether a language succeeds is if a miracle occurs. C got one, C++ got one, Java got one, Javascript got one. Python probably got one. I don't know of any others newer than Fortran. Julia and Rust still have a chance.

You can get what you need done and working in C++. The trouble is, it's harder to do and the result just doesn't look that nice. A simple example:

C++:

    typedef struct S { int x; } S;

D:

    struct S { int x; }

There are a lot of things like that, and it adds up.

I have never even once encountered any problem caused by the tag namespace.

I never, ever, typedef struct tag names. I have only ever seen typedefs like that in C headers. All C++ code I ever see looks like your D example.

I have to wonder if you meant to post something else, or if you have lost touch with what C++ code looks like.

I use the typedef version to head off problems. Anyhow, how about this:

C++:

    template<class T> T func(T t) { ... }

D:

    T func(T)(T t) { ... }

or

C++:

    void f(long);

    void test() {
        f(1); // calls f(long)
    }

    void f(int);

D:

    void f(long);

    void test() {
        f(1); // calls f(int)
    }

    void f(int);

or

C++:

    int f(int a[3]) { return a[4]; } // undefined behavior

D:

    int f(int[3] a) { return a[4]; } // index out of bounds error

Of course, you can use `array<int>` in C++, and all the above can be worked around, but it just is more work and doesn't look as good.

C++20:

  template <typename T> T func(T t) { return t; }
  auto func(auto t) { return t; }  // same, "abbreviated"

C++ is often not as nice to type as D, or as Rust. That's backward compatibility for you. But having literally tens of billions of lines of code in production, and millions of programmers who know how to use it, counts for a lot.

Your example here is C style though.

struct S { int x; };

is perfectly valid C++

Yeah, but that enables you to declare another variable named `S` and it'll compile. The tag name space is still there, and still causes problems. The typedef approach ensures you won't have problems.

People have learned to deal with the quirky behavior of the tag name space, but it's still quirky and serves no purpose.

I wrote Bjarne back in the 1980s that the tag name space should be removed from `class` as that wasn't necessary for backwards compatibility with C. He replied no as it would have broken compatibility with existing C++ code.

I see it less dramatically: like C# is Java with the benefit of hindsight, D is C++ with the benefit of hindsight. No need of compatibility with early bad decisions and undesirable features is an unexciting but important feature.

C++ will structurally never have a borrow checker, because it's simply not designed in a way for that to be possible.

Correct.

But a borrow checker does not change the set of possible programs. It only identifies the subset of possible programs that would need "unsafe" blocks.

In the absence of a borrow checker, libraries are left to carry the responsibility to define an API that is hard to misuse. Such an API could be slower than what one would define for a library to be used under a borrow checker. But code written to satisfy a borrow checker is sometimes slower than code that doesn't need to.

>But a borrow checker does not change the set of possible programs.

Once you have Turing completeness you have the full set of possible programs, end of story. Languages aren't about changing the set of possible programs, they're about making good ones easier to write, and bad ones harder.

Then there is nothing but ones and zeroes, and nothing to compare, and no insight to be had.

Yet, C++, D, and Rust are much more like one another than any of them is like any other language. Your Turing Completeness tells you less than nothing about any important distinction between them.

D has a prototype borrow checker now. I'll be talking about it at the April NWCPP meeting.

I wouldn't characterize JavaScript's surprise fortune as miraculous.

Miracles are Heaven sent, right? What does Hell send? Maledictions? https://www.powerthesaurus.org/miracle/antonyms

Nobody knows how to get a programming-language miracle.

Sun committed a billion dollars to promoting Java—and the opportunity-cost loss is probably a big part of what killed them. It still would not have been enough to secure a place for Java, except that Java offered MS sharecroppers a road to a sort of freedom. Ada got even more $promotion than Java, in its day, but faded.

C got its miracle on the coattails of Unix, C++ on C's. Javascript rode on Netscape. (Who remembers MS Silverlight? MS spent as much as Sun.)

Python, if does survive, got its miracle the hard way. Perl and Ruby once seemed more secure than Python does now. Rust and Julia are going the hard route.

All it takes to fade away is not getting that miracle, mo maledictions needed.

D is really underappreciated.

Did you ever feel the itch to add a 'trait' to access and manipulate the partial ordering set? Something like CLOS' method combinators or call-next-method (to call the next most specific function).

No, I never thought of it. I have no idea what purpose calling the next most specific function would serve. Besides, there are ways to call specific functions other than the best match - like casting the arguments to types that make it an exact match with the desired function.

Despite the power of D's overload mechanism, my advice is to use overloading modestly, not cleverly. You've written your best code when a newbie looks at it and remarks "pshaw, I could have written this! Why does Walter make so much money?"

It's one of those things where on rare occasion where it's applicable it really simplifies the code. Kind of like dynamically scoped variables.

It's been a while that I've hacked CL, but I remember method combinators being used in mixin-style programming[1]. A call-next-method is a simplification tool in that context, and it doesn't hard-couple your generic functions. With concepts now in C++, I wouldn't be surprised to see a resurgence of template-mixins, and there it really helps to have some introspection into the partial ordering.

[1] That is, Flavors mixins, not dlang mixins ;)

Well, I think they should rather react like this: "Wow, so Walter gets so much money because he writes much less convoluted code than what I would have come up with."

They will react that way when they stop being newbies.

Exactly.

Sometimes I think about the advice on how to carve a figure in stone - chip away anything that is not part of the figure.

The same applies to programming. Easy to say, hard to do.

> I have no idea what purpose calling the next most specific function would serve.

This is a replacement for calling the superclass, but it uses C3 method resolution order.

This reminds me that you can get the precedence list in Python with C.__mro__, similar to CLOS's (class-precedence-list C)