I've been learning Zig and it seems that Zig and D have a lot of things in common. With Zig one can readily import C code as well, and with `c-call-convention` any Zig function can be made callable from C.
However, I've run into lots of bugs in Zig so I got a little disillusioned... how do you think D compares with Zig? Is it able to produce as efficient and small binaries, cross-compile to most platforms, metaprogramming etc?
While i like Zig, it has many ergonomics issues that i just can't deal with.. and it has the tendency to make your code unnecessary verbose
- no operator overloading for your math type, you end up chaining methods..
- no function overloading, you have to do things like 'add(comptime T: type, x: antype, y: anytype)`
then: add(f32, myX, myY);
then be prepared with a shit ton of @floatCast(), it can't guess what type you use so you forced to be doubly explicit..
you end up with code that is barely readable
- unused as error, this one hurts a lot.. you can say goodbye to fast iteration time, if you make a game it'll be painful
Zig is still great, i plan to use it for some project, knowing how to use more language helps train your skills and understand pros/cons of features better
You can crosscompile with D too
ldc2 -mtriple=x86_64-windows-msvc -c foo.d
Metaprogramming is great, you get more power with D, mixin, proper templates, type introspection
You can link without the runtime if size is a concern, i haven't had any issues with it
when you expect things to be just 0, it is a pain to deal with and to remember...
Also the standard library, while useful, i wish it would make use of allocators
They have ``std.experimental.allocator`` packages, for some reason it still is experimental..
There is no tagged union.. you have to import a package for it ``std.sumtype``.. wich is bad when all other languages have built in support for that
Walter if you read this, please! union are useful, but lack of tagged union mean potential bugs in your union when you pick the wrong value...
Proposal for you:
enum MyTag { A, B, C}
union MyTaggedUnion: MyTag
{
DataA A,
DataB B,
DataC C
}
struct DataA{}
struct DataB{}
struct DataC{}
auto tgu = MyTaggedUnion.B;
switch (tgu)
{
case A:
tgu. /* implicit DataA */
break;
// need to implement every tags, or error
}
Invalid values, perhaps? Other than making initialization mandatory, this seems like a reasonable way of catching them. For integer types it's not really possible because all their values are valid.
import std.sumtype;
void main(){
struct A { int a; }
struct B { string b; }
struct C { bool c; }
alias TaggedUnion = SumType!(A, B, C);
auto tgu = TaggedUnion(B("hi"));
int i = tgu.match!(
(A a) => a.a,
(B b) => b.b.length,
(C c) => c.c * 5
);
assert(i == 2);
}
If you miss out a `match` handler for any of A, B, C you get a compile-time error. Or you can use a generic handler which will be instantiated for any type not explicitly handled.
https://dlang.org/phobos/std_sumtype.html
I'd take a language that have built in support for tagged union over having to import a module and rely on templates
I know of sumtype, and i think it is a mistake for D to rely on this for such important language feature
I'm not a language dev, so i can't do much to help, using switch/union/enum is more natural, is cleaner, and is easier to add support for IDEs, everyone on the same page
That's in areas like this where the language falls short, and i can see people instead choosing alternatives
> The good news is, I have not put a lot of effort so far into micro-optimizing the compile-time performance of match, so there is almost certainly room for improvement.
it is shame that it ended up in the standard library
once Walter will be gone, i will have no faith in the language anymore
All operations that are fed NaN as an operand produce a NaN result. This makes it very obvious when the initialization of a float has been neglected. Defaulting to 0.0 means uninitialization bugs are nearly impossible to detect.
> char default is 0xFF....
Same thing. It's intended to flush out uninitialization bugs.
Disclaimer, I've never used Zig, so the following are not comparative.
> Is it able to produce as efficient and small binaries,
There are compiler flags to disable linking to the D standard library and D runtime if you need small binaries (you can still use templates that end up in you binary) though most of the time that is more of a loss than gain (in terms of productivity), its not bloated unless you abuse templates a lot as would happen in C++.
As for speed of execution, don't use DMD if you care about the it. LDC (the LLVM D Compiler) and GDC (which is part of the GCC) are both strong optimisers.
cross-compile to most platforms,
Yes, use LDC. GDC, like GCC, is not a cross compiler by default though you can build it to be, DMD is X86(64) only.
> metaprogramming etc?
Oh, yes. Compile time function evaluation (referred to usually as CTFE) in combination with mixins (interpret string as code), `static foreach`, `static if` and (much safer than C++) templates makes for a very potent package.
If I want to use D as a scripting language, I would like to have access to at least the core parts of the standard library (strings, lists, hashmaps, etc.), which I can’t without GC. I really don’t have time and energy to implement my own data structures when trying to prototyping gameplay code.
> If I want to use D as a scripting language, I would like to have access to at least the core parts of the standard library (strings, lists, hashmaps, etc.), which I can’t without GC.
How is it a "scripting language" if you don't want a GC? I use D for the vast majority of my scripting these days, but it would be odd for me to avoid the GC. I would not even think about using it if I had to deal with that.
I wasn’t talking about GC in general, but the GC in Dlang. With the GC turned off in D you can’t use most of the standard library.
You can certainly use the std without relying on GC in languages like Rust, Swift, etc, but the important thing is that you can’t in D. I’m sure it can be technically done, but nobody has actually put the effort to do it.
D's standard lib is also a lot more mature than Zig's, obviously because of its age. I'd recommend D above Zig unless you want to contribute bug fixes to Zig.
> Just use your allocators with malloc/free, that is what i do (you do the same in zig, allocators)
If you do that, is it RAII like C++/Rust? Objects get destructed at end of scope, and members get destructed recursively? Or do you have to manually call `free()` on everything? (which, granted, is significantly easier in languages with `defer` mechanisms)
However, I've run into lots of bugs in Zig so I got a little disillusioned... how do you think D compares with Zig? Is it able to produce as efficient and small binaries, cross-compile to most platforms, metaprogramming etc?