7 ms·

I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development

I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.

bodge5000 3y ago
I'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern
- jsheard 3y ago
  Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.
  - felixgallo 3y ago
    as a long time game dev, I actively don't want operator overloading. That's some spooky action at a distance nonsense. I'm not sure I have seen a codebase that involved operator overloading, either, and I've worked in or near a good quantity of well-known titles.
    - jsheard 3y ago
      There's no accounting for taste, but the two major publicly available engines (Unreal and Unity) both use operator overloading in their standard math types.
    - Taywee 3y ago
      You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.
      - flohofwoe 3y ago
        FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6 https://www.godbolt.org/z/7zbxnncv6
        kprotty 3y ago
        Vectors in Zig are SIMD types. Vectors in games are probably algebraic types. Using SIMD for the latter may not be that useful if 1) specific elements are accessed frequently 2) transformations involve a different operation happen on each element.
        cyber_kinetist 3y ago
        First of all that only works with vectors, but I want operator overloading to also work on things like matrices or custom types (for example quaterions, or a symmat3 struct that represents a symmetric 3x3 matrix using only 6 floats). Additionally, for efficient math code you often want vector / matrix types in AOSOA fasion: for example Vec3<Float8> to store an AVX lane for each X/Y/Z component. I want vector/matrix operations to work on SIMD lanes, not just for scalar types, and Zig currently can't support math operators on these kinds of types.
        felixgallo 3y ago
        I have a marvelous proof that you can solve that with comptime but unfortunately the margins of this website are too small to contain it.
        lvass 3y ago
        Do us a pastebin, please.
        3y ago
    - chlorion 3y ago
      >That's some spooky action at a distance nonsense. In pretty much all languages operators are just sugar for calling a method. There is no difference other than an easier to read syntax. In rust for example, doing a + b is exactly the same as doing a.add(b). In python it's exactly the same as doing a.__add__(b). In C++, my understanding is that its sugar for a.operator+(b) or operator+(a, b). I think there are some arguments against operator overloading but "spooky action at a distance" doesn't seem to be a very good one to me.
- pjmlp 3y ago
  Not really, it is mostly around communities like Handmade, most studios couldn't care less and it doesn't fit most engines that they are using.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
- mr_00ff00 3y ago
  Would love to see zig in game dev. I’ve tried some rust and while I love rust in general, I find game dev in it a bit of a mess.
  - adastra22 3y ago
    Have you tried bevy? I’m starting with bevy for a non-game project, but I’m blown away by how simple it is to use once you get used to the magic.
    - the__alchemist 3y ago
      Bevy isn't on the same level as tools like UE and Godot.
      - Ygg2 3y ago
        To be fair Godot isn't on same level as UE.
      - adastra22 3y ago
        Depends on what you're doing. I'm writing a non-game app that requires a scenegraph, raycast mouse selection tool, and other tools of the sort typically required by games and provided by a game engine. But there's a lot of game stuff I don't need, and I need to make major customizations to the rendering engine. It ended up being easier to implement in bevy, due to its modularity, than it would have been in UE4 or Godot.
      - nextaccountic 3y ago
        Zig gamedev libraries aren't either
    - mr_00ff00 3y ago
      Maybe I need to give bevy a second go. My big issue is I felt I was learning to speak “bevy” instead of using rust. A lot of functions I wrote required queries of components, but the queries were built and called behind a magically wall. I don’t have much game dev experience though outside of simple games using libraries like raylib to just move and draw stuff. Maybe once things get complicated enough they are all like bevy.
TwentyPosts 3y ago
I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that. So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but it'd be clear that every usage of such an operator is a disguised function call. (And according to what Andrew Kelley said, it's all about not hiding function calls or complex operations in seemingly innocent 'overloaded' symbols.) If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms. Honestly, I am not particularly happy with any of these ideas, but I can't think of anything better either!
- ljlolel 3y ago
  Idea: allow some weird Unicode operators like Julia does. Then it’ll be clear the weird operator is doing something weird and new. And this already works in other languages. There are lots of Unicode
  - spenczar5 3y ago
    Writing greek symbols is sufficiently annoying that I always kind of resent code that does this. It’s not just about the first time you are writing code, but also when you are reviewing it, or trying to share a snippet with a coworker, or lots more scenarios. Maybe it’s just me, but writing ‘z = x ∇ d’ is really tedious.
    - kps 3y ago
      ∇ is near-worst-case since it's not even Greek. I think domain-specific keyboard layouts are as much of a good idea as language-specific layouts, but they're a nuisance to install on *nix (trivial on OS X). Using .XCompose is the most practical *nix approach, in the absence of program-specific methods like Julia's tab-completable backslash names.
      - 3y ago
audunw 3y ago
I like Zigs justification for not having general purpose operator overloading (no hidden function calls and loops) But I wish they added: 1. Ability to declare completely pure functions that have no loops except those which can be evaluated at compile time. Something with similar constraints as eBPF in other words. These could be useful in many contexts. 2. Ability to explicitly import overloaded operators, that can only be implemented using these pure guaranteed-to-finish-in-a-fixed-number-of-cycles functions. Then you'd get operator overloading that can be used to implement any kind of mathematical function, but not all kinds of crazy DSL-like stuff which is outside the scope of Zig (I have nothing against that, I've done crazy stuff in Ruby myself, but it's not suitable for Zig)
pron 3y ago
As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a problem that could be helped by the language. The problem is real and a language feature would work, but there are many such problems, and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code). What we try to ascertain is how big of a problem it is, how many programs or lines of code it affects, and is there possibly a single feature that could solve multiple problems at once. So I would ask you this: what portion of your program suffers from a lack of user-defined infix operators and how big of a problem is it overall? Even if it turns out that the problem is worth fixing in the language, it often makes sense to wait some years and then prioritise the various problems that have been reported. Zig's simplicity and its no-overload (not just operator overloads!) single-dispatch is among its greatest features, and meant to be one of its greatest draws.
- markisus 3y ago
  In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api.
  - hellcow 3y ago
    Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.
    - KerrAvon 3y ago
      Are you sure you would find this more ergonomically pleasing: assign(x, plus(a, plus(b, plus(c, b)))) When you could have: x = a + b + c + d; Or: (let x (+ a b c d)) ?
sigsev_251 3y ago
To be fair, there is an operator overloading proposal for C2y/C3a and there is at least one compiler that offers operator overloading as an extension.
tuhats 3y ago
I have played around with using @Vector for linear algebra. This removes the need for operator overloading for a vector type, which covers most use cases of operator overloading and I often in fact think is the only legitimate use case. I don't get to use `*` for matrix multiplication, but I have found I do not mind using a function for this. I have only been playing with this in small toy programs that don't to much serious linear algebra and I haven't looked at the asm I am generating with this approach, but I have been enjoying it so far!
kapperchino 3y ago
For the math stuff you can do things like a builder pattern where you can flatten the nested functions. But operator overloading is definitely preferred
flohofwoe 3y ago
Zig has a builtin @Vector type that might come in handy for most cases where in C++ a math library with operator overloading would be used: https://www.godbolt.org/z/7zbxnncv6 https://www.godbolt.org/z/7zbxnncv6 ...maybe one day there will also be a @Matrix builtin.
- jsheard 3y ago
  That still breaks if you layer any abstractions on top, for example if you wanted to build an AoSoA packet of Vec3s you'd have to define an addition of those in terms of a function. https://www.godbolt.org/z/v8Ta8hEbv https://www.godbolt.org/z/v8Ta8hEbv Zig is exactly the kind of language where you'd want to build a performance-oriented primitive like that, but AFAICT the language doesn't let you do it ergonomically.
  - flohofwoe 3y ago
    That's true, but OTH that's already getting into territory where operator overloading might start to become detrimental because it hides important implementation details which might not be expected from a simple '+'.
- throwawaymaths 3y ago
  Probably not. @Vector is not a mathematical vector, it's SIMD. it makes sense because there are times when those live in registers and a poly fill for stack memory isn't burdensome. @Matrix makes less sense because when it gets big, where are you getting memory from?
  - flohofwoe 3y ago
    For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax - basically what this Clang extension offers: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...).

bodge5000 3y ago

I'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern

jsheard 3y ago
Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.
- felixgallo 3y ago
  as a long time game dev, I actively don't want operator overloading. That's some spooky action at a distance nonsense. I'm not sure I have seen a codebase that involved operator overloading, either, and I've worked in or near a good quantity of well-known titles.
  - jsheard 3y ago
    There's no accounting for taste, but the two major publicly available engines (Unreal and Unity) both use operator overloading in their standard math types.
  - Taywee 3y ago
    You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.
    - flohofwoe 3y ago
      FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6 https://www.godbolt.org/z/7zbxnncv6
      - kprotty 3y ago
        Vectors in Zig are SIMD types. Vectors in games are probably algebraic types. Using SIMD for the latter may not be that useful if 1) specific elements are accessed frequently 2) transformations involve a different operation happen on each element.
      - cyber_kinetist 3y ago
        First of all that only works with vectors, but I want operator overloading to also work on things like matrices or custom types (for example quaterions, or a symmat3 struct that represents a symmetric 3x3 matrix using only 6 floats). Additionally, for efficient math code you often want vector / matrix types in AOSOA fasion: for example Vec3<Float8> to store an AVX lane for each X/Y/Z component. I want vector/matrix operations to work on SIMD lanes, not just for scalar types, and Zig currently can't support math operators on these kinds of types.
        felixgallo 3y ago
        I have a marvelous proof that you can solve that with comptime but unfortunately the margins of this website are too small to contain it.
        lvass 3y ago
        Do us a pastebin, please.
        3y ago
  - chlorion 3y ago
    >That's some spooky action at a distance nonsense. In pretty much all languages operators are just sugar for calling a method. There is no difference other than an easier to read syntax. In rust for example, doing a + b is exactly the same as doing a.add(b). In python it's exactly the same as doing a.__add__(b). In C++, my understanding is that its sugar for a.operator+(b) or operator+(a, b). I think there are some arguments against operator overloading but "spooky action at a distance" doesn't seem to be a very good one to me.
pjmlp 3y ago
Not really, it is mostly around communities like Handmade, most studios couldn't care less and it doesn't fit most engines that they are using.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
mr_00ff00 3y ago
Would love to see zig in game dev. I’ve tried some rust and while I love rust in general, I find game dev in it a bit of a mess.
- adastra22 3y ago
  Have you tried bevy? I’m starting with bevy for a non-game project, but I’m blown away by how simple it is to use once you get used to the magic.
  - the__alchemist 3y ago
    Bevy isn't on the same level as tools like UE and Godot.
    - Ygg2 3y ago
      To be fair Godot isn't on same level as UE.
    - adastra22 3y ago
      Depends on what you're doing. I'm writing a non-game app that requires a scenegraph, raycast mouse selection tool, and other tools of the sort typically required by games and provided by a game engine. But there's a lot of game stuff I don't need, and I need to make major customizations to the rendering engine. It ended up being easier to implement in bevy, due to its modularity, than it would have been in UE4 or Godot.
    - nextaccountic 3y ago
      Zig gamedev libraries aren't either
  - mr_00ff00 3y ago
    Maybe I need to give bevy a second go. My big issue is I felt I was learning to speak “bevy” instead of using rust. A lot of functions I wrote required queries of components, but the queries were built and called behind a magically wall. I don’t have much game dev experience though outside of simple games using libraries like raylib to just move and draw stuff. Maybe once things get complicated enough they are all like bevy.

TwentyPosts 3y ago

I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that. So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but it'd be clear that every usage of such an operator is a disguised function call. (And according to what Andrew Kelley said, it's all about not hiding function calls or complex operations in seemingly innocent 'overloaded' symbols.) If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms. Honestly, I am not particularly happy with any of these ideas, but I can't think of anything better either!

ljlolel 3y ago
Idea: allow some weird Unicode operators like Julia does. Then it’ll be clear the weird operator is doing something weird and new. And this already works in other languages. There are lots of Unicode
- spenczar5 3y ago
  Writing greek symbols is sufficiently annoying that I always kind of resent code that does this. It’s not just about the first time you are writing code, but also when you are reviewing it, or trying to share a snippet with a coworker, or lots more scenarios. Maybe it’s just me, but writing ‘z = x ∇ d’ is really tedious.
  - kps 3y ago
    ∇ is near-worst-case since it's not even Greek. I think domain-specific keyboard layouts are as much of a good idea as language-specific layouts, but they're a nuisance to install on *nix (trivial on OS X). Using .XCompose is the most practical *nix approach, in the absence of program-specific methods like Julia's tab-completable backslash names.
    - 3y ago

audunw 3y ago

I like Zigs justification for not having general purpose operator overloading (no hidden function calls and loops) But I wish they added: 1. Ability to declare completely pure functions that have no loops except those which can be evaluated at compile time. Something with similar constraints as eBPF in other words. These could be useful in many contexts. 2. Ability to explicitly import overloaded operators, that can only be implemented using these pure guaranteed-to-finish-in-a-fixed-number-of-cycles functions. Then you'd get operator overloading that can be used to implement any kind of mathematical function, but not all kinds of crazy DSL-like stuff which is outside the scope of Zig (I have nothing against that, I've done crazy stuff in Ruby myself, but it's not suitable for Zig)

pron 3y ago

As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a problem that could be helped by the language. The problem is real and a language feature would work, but there are many such problems, and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code). What we try to ascertain is how big of a problem it is, how many programs or lines of code it affects, and is there possibly a single feature that could solve multiple problems at once. So I would ask you this: what portion of your program suffers from a lack of user-defined infix operators and how big of a problem is it overall? Even if it turns out that the problem is worth fixing in the language, it often makes sense to wait some years and then prioritise the various problems that have been reported. Zig's simplicity and its no-overload (not just operator overloads!) single-dispatch is among its greatest features, and meant to be one of its greatest draws.

markisus 3y ago
In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api.
- hellcow 3y ago
  Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.
  - KerrAvon 3y ago
    Are you sure you would find this more ergonomically pleasing: assign(x, plus(a, plus(b, plus(c, b)))) When you could have: x = a + b + c + d; Or: (let x (+ a b c d)) ?

sigsev_251 3y ago

To be fair, there is an operator overloading proposal for C2y/C3a and there is at least one compiler that offers operator overloading as an extension.

tuhats 3y ago

I have played around with using @Vector for linear algebra. This removes the need for operator overloading for a vector type, which covers most use cases of operator overloading and I often in fact think is the only legitimate use case. I don't get to use `*` for matrix multiplication, but I have found I do not mind using a function for this. I have only been playing with this in small toy programs that don't to much serious linear algebra and I haven't looked at the asm I am generating with this approach, but I have been enjoying it so far!

kapperchino 3y ago

For the math stuff you can do things like a builder pattern where you can flatten the nested functions. But operator overloading is definitely preferred

flohofwoe 3y ago

Zig has a builtin @Vector type that might come in handy for most cases where in C++ a math library with operator overloading would be used: https://www.godbolt.org/z/7zbxnncv6 https://www.godbolt.org/z/7zbxnncv6 ...maybe one day there will also be a @Matrix builtin.

jsheard 3y ago
That still breaks if you layer any abstractions on top, for example if you wanted to build an AoSoA packet of Vec3s you'd have to define an addition of those in terms of a function. https://www.godbolt.org/z/v8Ta8hEbv https://www.godbolt.org/z/v8Ta8hEbv Zig is exactly the kind of language where you'd want to build a performance-oriented primitive like that, but AFAICT the language doesn't let you do it ergonomically.
- flohofwoe 3y ago
  That's true, but OTH that's already getting into territory where operator overloading might start to become detrimental because it hides important implementation details which might not be expected from a simple '+'.
throwawaymaths 3y ago
Probably not. @Vector is not a mathematical vector, it's SIMD. it makes sense because there are times when those live in registers and a poly fill for stack memory isn't burdensome. @Matrix makes less sense because when it gets big, where are you getting memory from?
- flohofwoe 3y ago
  For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax - basically what this Clang extension offers: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...).