I've never used D, but aren't you kind of making the author's point?
If you disable GC in D, and end up with something equivalent to Zig, then why not use Zig?
If you disable GC in D, and end up with something equivalent to Zig, then why not use Zig?
- Multiple production-ready compilers. (Zig does not claim to be production-ready yet.) https://wiki.dlang.org/Compilers
- A more stable API. (Zig's authors rightly expect it to change before 1.0.)
- A package manager (dub) and repository: https://code.dlang.org/ (Zig will get support for these but doesn't even have an HTTP client needed to back package fetching yet.)
- An HTTP server and client with SSL/TLS support. (Zig is too new to have these, although community libs are starting to spring up to fill the gaps.)
- Better documentation, including a very accessible tour at https://tour.dlang.org/ and books such as http://erdani.org/tdpl/.
Zig may get all of these in time but D had quite the head start. D is a good language and I wish it got more attention.
99% of the D ecosystem uses the GC. You probably can't use most of it if you put @nogc on main.
99% of the D ecosystem of docs and articles assumes using the GC. You're going to struggle learning how to build something without it. You are kind of on your own.
Also @nogc only was added in 2014, it's not that old.
So given that, I honestly doubt that @nogc is much more mature than Zig, and is probably more difficult to learn how to use in practice, given that it's not a normal thing to do.
D always looked nice conceptually. But the syntax!
Most likely I would use it actively if it wouldn't look like C.
The type annotations are "on the wrong side". Type inference is barely-there (`auto` is a joke). It's littered with superfluous braces and semicolons.
I would really love it if they would change the syntax, and the result would look more like the new syntax in Scala 3.
2. pointers to the stack cannot escape the lifetime of the stack frame
3. cannot conflate pointers with non-pointers
4. cannot have uninitialized pointers
5. cannot do arithmetic on pointers (must use array slices, which come with array bounds checking)
6. cannot pass the same mutating pointer to a function more than once
There are many more of these. They may seem burdensome and restrictive, but actually are not. If you really want to do these things, there is a "system" annotation that can be used.