3 ms·

While this solves one of the issues I've had with Zig, it doesn't seem very flexible. I would love to the same thing for (tuples of) variable-length arrays, arr

While this solves one of the issues I've had with Zig, it doesn't seem very flexible. I would love to the same thing for (tuples of) variable-length arrays, arrays of different lengths etc. Now my implementation will still look completely different in slightly different situations. Yes, a flexible solution (a zip function) would probably need iterators but why would introducing them be such a big problem? (FWIW, I know that one can emulate looping over iterators with while() and optionals[0] but it feels a bit dirty.) More generally, my biggest gripe with Zig has been a lack of expressiveness: Things like deep equality checks between structs, arrays and optionals; looping over different kinds of containers; … should just work™. Sure, I understand that Zig doesn't want hidden control flow but OTOH explicit control flow everywhere often just gets in the way of readability and of implementing business logic. I usually follow the approach "Implement first, optimize later" but with Zig the implementation will look completely different depending on which optimization or data structure I choose, so I need to think about optimizations from the start if I don't want to rewrite everything later. I should mention, though, I'm very used to Python these days and haven't written C or C++ in ages, so maybe that sort of culture shock is somewhat expected. Anyway, I'm still excited about the language and my impression is that Andrew Kelley is very open to new suggestions and new ideas, so things will certainly still change in one way or another till v1.0. [0]: https://news.ycombinator.com/item?id=34958051 https://news.ycombinator.com/item?id=34958051

AndyKelley 4y ago
There is no "just work" for deep equality. The standard library would have to make decisions on behalf of the application that it has no business making. I can tell you right now that while there will be many upcoming language changes, none of them will be comfy to Python programmers. Zig is very much an imperative language. Or perhaps think of it as a declarative DSL for outputting machine code.
- _a_a_a_ 4y ago
  > a declarative DSL for outputting machine code and thanks for the laugh
- codethief 4y ago
  Thanks for your message, Andrew! 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 https://ziglang.org/documentation/master/#Zen
  - munificent 4y ago
    > Why can't I just compare these two regions using `A == B` to make sure they are equal? Why is shallow equality useful? You could have `A == B` be true, but then as soon as you wrap pointers to them in C and D, now `C == D` is false.
- cultureswitch 4y ago
  Deep equality is easy as long as the user has properly implemented it for all the types involved. Standard libraries implementing deep equality correctly on standard collections should really not be a problem at all.
  - deleted 4y ago
    [deleted]
- codethief 4y ago
  I need to correct myself: I only realized now that in my original message I put "deep equality" where it had no business of being. I meant to write "equality" or "shallow equality", i.e. simple comparison of the memory regions the variables represent, as outlined in my other response to you. My apologies for the confusion!
alpaca128 4y ago
> I need to think about optimizations from the start if I don't want to rewrite everything later Deep equality checks don't prevent the need for minor rewrites in other cases, like when you change a widely used type's definition. Rewrite code during optimizations or rewrite the project once Python isn't fast enough? I don't know, both can be very cumbersome.

AndyKelley 4y ago

There is no "just work" for deep equality. The standard library would have to make decisions on behalf of the application that it has no business making. I can tell you right now that while there will be many upcoming language changes, none of them will be comfy to Python programmers. Zig is very much an imperative language. Or perhaps think of it as a declarative DSL for outputting machine code.

_a_a_a_ 4y ago
> a declarative DSL for outputting machine code and thanks for the laugh
codethief 4y ago
Thanks for your message, Andrew! 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 https://ziglang.org/documentation/master/#Zen
- munificent 4y ago
  > Why can't I just compare these two regions using `A == B` to make sure they are equal? Why is shallow equality useful? You could have `A == B` be true, but then as soon as you wrap pointers to them in C and D, now `C == D` is false.
cultureswitch 4y ago
Deep equality is easy as long as the user has properly implemented it for all the types involved. Standard libraries implementing deep equality correctly on standard collections should really not be a problem at all.
- deleted 4y ago
  [deleted]
codethief 4y ago
I need to correct myself: I only realized now that in my original message I put "deep equality" where it had no business of being. I meant to write "equality" or "shallow equality", i.e. simple comparison of the memory regions the variables represent, as outlined in my other response to you. My apologies for the confusion!

alpaca128 4y ago

> I need to think about optimizations from the start if I don't want to rewrite everything later Deep equality checks don't prevent the need for minor rewrites in other cases, like when you change a widely used type's definition. Rewrite code during optimizations or rewrite the project once Python isn't fast enough? I don't know, both can be very cumbersome.