> D also has a @nogc mode, but it feels like giving up on 60% of the language’s power.
Without the GC, D has exactly the same 'power' as Zig have..
I feel that the poster is a bit misleading: he chose Zig instead of D because Zig, being newer, is more fashionable, not because of an imaginary technical reason.
If there's a technical reason, it's not written in the article.
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.
Maybe. But could as well be the GC stigma being too strong. It isn't without reason that there's a post on official blog named "don't fear the reaper."
It's the community around D, the micro design decisions. If everything online presupposes you're using garbage collection most of the time, if everything in the language also makes that supposition sure possible to still go against the grain but it does feel like you're going against the grain.
Feel and community support is as important as anything else in a language decision.
It is, at least, more battle tested.
> Zig is a programming language, but it also ships with a package manager
Which is not true:
https://github.com/ziglang/zig/issues/943
> Zig has no macros and no metaprogramming
Literally from Zig's homepage (https://ziglang.org/):
"Comptime - a fresh approach to metaprogramming"
The rest of the arguments are very weak in my opinion.
You’re thinking at a different level of abstraction to the Zig developers. Summing a primitive type is going to be turned into a couple of machine opcodes (but no branch instruction) and will usually be constant time, whereas an explicit function call will require pushing pc to the stack and jumping elsewhere, executing any number of instructions once there, taking an arbitrarily long time, making it more difficult to reason about.
Because on your typical arm mcu, x/y is a function call to a definitively non-constant time function.
And lets not forget soft-fp. Every single floating point op is a function call...
With most languages you need significantly more context than you do in Zig - in C you need to know what preprocessor shenanigans might be going on; in C++ pretty much anything could be happening (operator overloads, virtual functions, constructors, destructors, who knows what else). With Rust you need to know what traits are imported, and if proc macros are involved then anything goes.
I created https://github.com/ziglang/www.ziglang.org/pull/228 let's see if it gets accepted :)