Just to be clear, I didn't mean any offense and maybe my critique wasn't as well-balanced as it could have been. So far, coding in Zig has been a fun ride, despite the occasional obstacles I've run into!
> There is no "just work" for deep equality
Say I have two variables A and B of the same struct type. Each points to a finite region in memory of the same size. Why can't I just compare these two regions using `A == B` to make sure they are equal? Yes, one can obviously come up with alternative definitions of what equality might mean for structs (only compare certain subfields etc.) but wouldn't the aforementioned definition be a good default that would work in the majority of cases?
Alternatively, there is `std.testing.expectEqualDeep()` which walks through all fields but as far as I know there is no equivalent for production code(?)
> none of them will be comfy to Python programmers
Oh I think the multi-sequence for loops feature already makes Zig more comfy! :)
Just to be clear: I wouldn't want Zig to be another Python. While I like Python from a developer experience POV, it is dictionaries and magic methods all the way down and often unnecessarily slow and complex.
I still think one could find a good balance between DX and full low-level control, though. One could e.g. have one convenient way to express a certain problem that gives you medium control over performance (e.g. the `==` example above) and one or more fine-tuned, but possibly less concise ways of expressing the problem that provide full control but require more lines of code. In the struct equality example the latter would mean defining some kind of `eql()` function that would be optimized to the struct type (e.g. compare certain fields first as they are more likely to differ etc.). Would this violate the Zen of Zig?[0]
> Only one obvious way to do things.
After all, there is also
> Favor reading code over writing code
Right now, at least, I often run into situations where I don't know of any obvious way to solve my problem. Then I end up writing lengthy code to tell Zig what I want and end up with code that's so-so on the fun-to-read scale.
> > Why can't I just compare these two regions using `A == B` to make sure they are equal?
> Why is shallow equality useful?
Of course deep equality checks are useful, too, I'm not denying that. But in many cases you are not dealing with several layers of structs nested through pointers. You just want to compare simple structs and be done with it, without having to write an eql() function for every single case.
Besides, many other operations in Zig operate directly on the memory, so why should == be any different?
Just to be clear, I didn't mean any offense and maybe my critique wasn't as well-balanced as it could have been. So far, coding in Zig has been a fun ride, despite the occasional obstacles I've run into!
> There is no "just work" for deep equality
Say I have two variables A and B of the same struct type. Each points to a finite region in memory of the same size. Why can't I just compare these two regions using `A == B` to make sure they are equal? Yes, one can obviously come up with alternative definitions of what equality might mean for structs (only compare certain subfields etc.) but wouldn't the aforementioned definition be a good default that would work in the majority of cases?
Alternatively, there is `std.testing.expectEqualDeep()` which walks through all fields but as far as I know there is no equivalent for production code(?)
> none of them will be comfy to Python programmers
Oh I think the multi-sequence for loops feature already makes Zig more comfy! :)
Just to be clear: I wouldn't want Zig to be another Python. While I like Python from a developer experience POV, it is dictionaries and magic methods all the way down and often unnecessarily slow and complex.
I still think one could find a good balance between DX and full low-level control, though. One could e.g. have one convenient way to express a certain problem that gives you medium control over performance (e.g. the `==` example above) and one or more fine-tuned, but possibly less concise ways of expressing the problem that provide full control but require more lines of code. In the struct equality example the latter would mean defining some kind of `eql()` function that would be optimized to the struct type (e.g. compare certain fields first as they are more likely to differ etc.). Would this violate the Zen of Zig?[0]
> Only one obvious way to do things.
After all, there is also
> Favor reading code over writing code
Right now, at least, I often run into situations where I don't know of any obvious way to solve my problem. Then I end up writing lengthy code to tell Zig what I want and end up with code that's so-so on the fun-to-read scale.
[0]: https://ziglang.org/documentation/master/#Zen