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.