I actually think I do. Go does offer a couple of primitives for poking into memory, but it is my opinion that a systems language needs much more refined control over memory layout and allocation.
Still, I think you raised valid question in the first part of your message, though the second is a bit offensive and I also thank Andrei for his clarification and use the opportunity to congratulate for this milestone of D language. I like D and even if I use C++ at work, I know I'd enjoy using D especially for the features that let my code "see" and "build" the other parts of the code.
I think that a lot of confusion has been caused by Go using the term "systems language," because (as I understand it) Go doesn't mean it in the same way that C++ and D do. The Go folks seem to be thinking systems in the sense of large networks of computers and the like (the kind of stuff that Google typically does), whereas the C++ and D folks are thinking systems in terms of stuff like operating systems. What Go is trying to do does not necessarily require low-level primitives (though it can benefit from them), whereas what C++ and D are trying to do does require such primitives.
The problem is by deciding that they can use "systems language" (which they dropped) because "system" means "a set of connected things or parts forming a complex whole" results in every language falling under "systems language."
Others have been using it to distinguish languages suitable for writing operating systems/drivers years before Go introduced this confusion.
When I hear "systems programmer" I think computer-to-computer. Therefore when I hear "systems language" I think computer-to-computer even absent Go's use of the term. I not be disappointed if a systems language were not appropriate for creating operating systems.
Now does it allow unsafe memory access, or does it not?
And does the unsafe package allow you to build a C-style manual allocator or not (regardless of whether it integrates with Go's new or make operators)?
