Most active commenters
  • jsheard(3)
  • adastra22(3)

←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 27 comments | | HN request time: 0.86s | source | bottom
Show context
jsheard ◴[] No.36150389[source]
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.
replies(8): >>36150475 #>>36150541 #>>36150795 #>>36150946 #>>36151013 #>>36151746 #>>36151792 #>>36152172 #
1. bodge5000 ◴[] No.36150475[source]
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
replies(3): >>36150560 #>>36150748 #>>36151102 #
2. jsheard ◴[] No.36150560[source]
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.
replies(1): >>36150721 #
3. felixgallo ◴[] No.36150721[source]
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.
replies(3): >>36150843 #>>36151267 #>>36160066 #
4. pjmlp ◴[] No.36150748[source]
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.
replies(2): >>36161455 #>>36161478 #
5. jsheard ◴[] No.36150843{3}[source]
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.
6. mr_00ff00 ◴[] No.36151102[source]
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.
replies(2): >>36152719 #>>36158754 #
7. Taywee ◴[] No.36151267{3}[source]
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.
replies(1): >>36152896 #
8. adastra22 ◴[] No.36152719[source]
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.
replies(2): >>36153938 #>>36154063 #
9. flohofwoe ◴[] No.36152896{4}[source]
FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6
replies(2): >>36154682 #>>36154931 #
10. the__alchemist ◴[] No.36153938{3}[source]
Bevy isn't on the same level as tools like UE and Godot.
replies(3): >>36154350 #>>36155653 #>>36176465 #
11. mr_00ff00 ◴[] No.36154063{3}[source]
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.

replies(1): >>36156019 #
12. Ygg2 ◴[] No.36154350{4}[source]
To be fair Godot isn't on same level as UE.
13. kprotty ◴[] No.36154682{5}[source]
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.
14. cyber_kinetist ◴[] No.36154931{5}[source]
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.

replies(1): >>36155544 #
15. felixgallo ◴[] No.36155544{6}[source]
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.
replies(3): >>36156503 #>>36161875 #>>36165689 #
16. adastra22 ◴[] No.36155653{4}[source]
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.
17. adastra22 ◴[] No.36156019{4}[source]
This is true on both fronts, I think. Bevy magics away the interface between you and the engine via the ECS macros, in a way that is very unusual for a systems programming language like Rust. But that's more or less how all game engines are these days from what I understand.
18. lvass ◴[] No.36156503{7}[source]
Do us a pastebin, please.
19. i_am_a_peasant ◴[] No.36158754[source]
I gave it a go with openGL and Rust, was great until I needed some external C++ libraries.. Then I lost motivation and rewrote the whole thing in C++
replies(1): >>36158882 #
20. shrimp_emoji ◴[] No.36158882{3}[source]
Name checks out

<33

replies(1): >>36159160 #
21. i_am_a_peasant ◴[] No.36159160{4}[source]
absolutely
22. chlorion ◴[] No.36160066{3}[source]
>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.

23. ◴[] No.36161455[source]
24. ◴[] No.36161478[source]
25. QQ00 ◴[] No.36161875{7}[source]
You can use pastebin, or even better, use github gist.
26. another2another ◴[] No.36165689{7}[source]
I think you have briefly deluded yourself with an irretrievable idea.
27. nextaccountic ◴[] No.36176465{4}[source]
Zig gamedev libraries aren't either