←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 9 comments | | HN request time: 2.099s | 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. flohofwoe ◴[] No.36152172[source]
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

...maybe one day there will also be a @Matrix builtin.

replies(3): >>36152928 #>>36153017 #>>36154505 #
2. jsheard ◴[] No.36152928[source]
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

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.

replies(1): >>36153332 #
3. throwawaymaths ◴[] No.36153017[source]
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?

replies(1): >>36153241 #
4. flohofwoe ◴[] No.36153241[source]
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-...).

replies(2): >>36154544 #>>36159575 #
5. flohofwoe ◴[] No.36153332[source]
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 '+'.
6. Conscat ◴[] No.36154505[source]
It's a LOT worse than C++ SIMD libraries.

In C++ (EVE, Vc, Highway, xsimd, stdlib), you can specify the ABI of a vector, which allows you to make platform specific optimizations in multifunctions. Or you can write vector code of a lowest-common-denominator width (like 16 bytes, rather than specifying the number of lanes), which runs the same on NEON and SSE2. Or you can write SIMD that is automatically natively optimized for just a single platform. These features are available on every notable C++ SIMD library, and they're basically indispensable for serious performance code.

7. cmbothwell ◴[] No.36154544{3}[source]
You might like Odin, it has a similar philosophy to Zig and supports swizzling:

https://odin-lang.org/docs/overview/#swizzle-operations

Matrix types are also built in:

https://odin-lang.org/docs/overview/#matrix-type

I’ve thought for a little while that Odin could be a secret weapon for game dev and similar pieces of software.

replies(1): >>36155740 #
8. flohofwoe ◴[] No.36155740{4}[source]
I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers:

https://github.com/floooh/sokol-odin

It's a very enjoyable language!

9. throwawaymaths ◴[] No.36159575{3}[source]
Sure, but people are going to want to use operator overloading for, e.g. dl/ml