I'm not sure 'targeted' would be the correct term, at least for Go. Go initially was targeting C++ devs(however ambitious and failed that attempt may have been) by offering this stripped down new language that more resembles C.
I've always much preferred C style to C++/D/Rust based mainly on readability and how small the language felt. I completely agree though that Go has given me this similar feeling - to me it really is a modern C. That said, I'm not sure how many C devs are going to like the bounds put in place by Go, or the mandatory GC.
I am, admittedly, a big fan of go also. For me, it has taken from both C and Python use cases, which I think says a lot about its versatility.
The D statement may be accurate, I've never done anything with D and only minimal brush ins with C++ - but to my untrained eyes, they seem pretty similar.
Except that the go developers explicitly stated their design goal was to replace C++ for their needs, not C. And that completely failed, and now the focus is on pulling in python devs.
I jumped into Go bandwagon early on, even tried to do some initial contributions. Mostly because Go has an Oberon feel to it. A GC enabled systems programming language I used for a while in the mid-90's.
However, I quickly became disappointed with Go's spartan design, given my broad experience across languages and paradigms.
That is why somehow I feel it is more indicated for C developers, that could live with a GC enabled language.
As they would mostly getting type safety and a few more features, whereas developers from other languages are mostly giving away features.
Yes, but from what I've learn of the original developers, "replace C++ for their needs" means, "we are using C++ currently, we don't want to, so we're making a language which incorporates a core which helps our tasks (goroutines). To do this we will fix up some issues we have with C."
Rust has much less emphasis on CTFE than D, and instead has a very extreme focus on zero-cost memory safety (and, following from that, a concomitant focus on easy concurrency).
D also owes more of its ancestry to C++, while Rust takes a lot of its inspiration from the ML family of languages.
Both languages are gunning to appeal to C++ programmers, and they're both worthy in this regard depending on your use case. The C++ pie is more than big enough to let both languages thrive independently (and their underlying philosophies are different enough that I expect very little overlap between their communities).
D is mature and actually usable, Rust is in alpha stages at best. The current outlook seems to be that they should be fairly comparable one day, but right now making such comparisons wouldn't be really fair. We don't even know yet what the final form of Rust will be like.
I'd say the biggest differences are (a) Rust is more functional (preferring algebraic data types over OO, pattern matching, immutability by default, typeclasses over templates); (b) Rust is newer and younger; (c) Rust has safe manual memory management, enforcing memory safety even if the GC is not used. Of these, I think (c) is the most fundamental difference: it gives the language a very different feel and niche, at the cost of a learning curve.
Go is targeted for developers that can move out of C in their use cases.
D is targeted for developers that can move out of C++ in their use cases.