5 ms·

Zig is still new, so it has room to improve While i like Zig, it has many ergonomics issues that i just can't deal with.. and it has the tendency to make your

Zig is still new, so it has room to improve 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

Shadonototra 4y ago
While D is great, it also has some issues - float default is NaN, why... just WHY!!!!! - char default is 0xFF.... 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 }
- jhgb 4y ago
  > float default is NaN, why... just WHY!!!!! > char default is 0xFF.... 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.
  - Shadonototra 4y ago
    I grew to agree, but that doesn't mean that's not annoying.. i'm nitpicking
- WalterBright 4y ago
  > float default is NaN, why... just WHY!!!!! 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.
- ntrel 4y ago
  Why is your proposal better than this: 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 https://dlang.org/phobos/std_sumtype.html
  - Shadonototra 4y ago
    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 https://github.com/dlang/phobos/blob/master/std/sumtype.d https://github.com/dlang/phobos/blob/master/std/sumtype.d a mess of templates and imports to std.traits using this will make your compile speed tank.. another reason to avoid it's very sad that people recommend this instead of asking for built-in version, makes me sometimes reconsider my choice to use the language if they expect language improvements to be templates, what atrocity will be added next? this is on the same level as std::bool from C++
    - Shadonototra 4y ago
      https://forum.dlang.org/post/bkgvdewkjwthmlfemnjm@forum.dlang.org https://forum.dlang.org/post/bkgvdewkjwthmlfemnjm@forum.dlan... > 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
    - germandiago 4y ago

Shadonototra 4y ago

While D is great, it also has some issues - float default is NaN, why... just WHY!!!!! - char default is 0xFF.... 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 }

jhgb 4y ago
> float default is NaN, why... just WHY!!!!! > char default is 0xFF.... 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.
- Shadonototra 4y ago
  I grew to agree, but that doesn't mean that's not annoying.. i'm nitpicking
WalterBright 4y ago
> float default is NaN, why... just WHY!!!!! 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.
ntrel 4y ago
Why is your proposal better than this: 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 https://dlang.org/phobos/std_sumtype.html
- Shadonototra 4y ago
  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 https://github.com/dlang/phobos/blob/master/std/sumtype.d https://github.com/dlang/phobos/blob/master/std/sumtype.d a mess of templates and imports to std.traits using this will make your compile speed tank.. another reason to avoid it's very sad that people recommend this instead of asking for built-in version, makes me sometimes reconsider my choice to use the language if they expect language improvements to be templates, what atrocity will be added next? this is on the same level as std::bool from C++
  - Shadonototra 4y ago
    https://forum.dlang.org/post/bkgvdewkjwthmlfemnjm@forum.dlang.org https://forum.dlang.org/post/bkgvdewkjwthmlfemnjm@forum.dlan... > 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
  - germandiago 4y ago