The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.

It might look like c++ but I can't say it 'feels' the same. The lack of header files in D immediately jumps to mind. D's module system is totatlly different from C++'s preprocessor. Ranges and slices are a big part in D programming that's a fair bit different than the way things are usually done in C++. Interfaces, Classes, structs are handled differently.

The similarities are more surface deep once you start learning more about the different features and tools D offers.

Not really, it doesn't feel like C++. D fixes many C++ annoyances, has a GC, doesn't have the annoying preprocessor, header files.

Walter Bright did try to make C++ better, remember that D came along after he wrote the Digital Mars C++ compiler.

C++ has also improved in the meantime.

I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.

It is less about how it feels and more about how it looks.

And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.

That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".

1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.

> 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem.

Now tell me why every OOP codebase I look at has this problem. ;-)

The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.

Ah the beauty of use-after-free and memory corruption issues. /s

Try to find one here: https://github.com/jstimpfle/language

Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it.

As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Sure, I'm just saying that a lot of it is due to unsuitable approaches.

If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

Let me know what problems you find!

I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.