I've asked in their Discord, Andrew Kelley himself passed on commenting (I know his stance, every C++ dev wants their fav feature), but the reality remains that it's just infeasible to do with a DSL so it's just the wrong language for writing graphics code.
It does seem that tensors are one of the core abstractions for modern ML systems. I've heard people joke that AI is just matrix multiplication. Python is such a flexible language that creating abstractions around its syntax was super easy. I believe that was part of the reason Python has come to dominate this space (not the only reason obviously).
I too felt the same as you, but as a distant admirer of Zig. I totally understand that operator overloading can be misused. But I have an intuition that at least providing operators for linear algebra (and probably complex/quaternion) is a really important feature for any languages from this point in history going forward.
1. https://www.youtube.com/watch?v=SEwTjZvy8vw&ab_channel=LLVM
Not sure where the joke is, today's deep learning based AI models are literally matrix multiplications with learned weights.
providing operators for linear algebra (and probably complex/quaternion) is a really important feature for any languages from this point in history going forward.
I'm still a happy Zig user though, and hey, there's still time before 1.0.
This isn't a pedantic nerd snipe; the point is that operator overloading really is indispensable in certain contexts.
C# has operator overloading and during my whole career I have never seen it abused so hard that people needed to ban it, let alone write guidelines and a lot of shops adopting it.
I barely see anyone use it not for really good cases like graphics.
The only interesting case was using "/" operator for Path Combines so "home" / "folder1" performs Path.Combine("home", "folder1")
but still, that was PoC or lib, not even prod.
So, is it about community, some culture or actually what?
C++ also allows you to overload short-circuiting operators, but of course your overload can't short-circuit so you just silently destroyed an important feature. Why ?
As others have pointed out, several languages have been able to provide this feature without causing half the mess and disappointment. Ten years ago if you said move assignment semantics are a bad idea you might persuade people because the C++ move semantics are messy, but hey, turns out a fresh language is able to just provide the destructive move developers actually wanted (but couldn't pull off for C++) and that's really nice.
cout << "foo" << endl;
Seems like there is a bunch of interesting low level languages gaining steam at the moment.
Or is it that the three years it’s been around indicate it will never progress?
Also it seems like even the discussion of Geometric Algebra has been covered before 3 years ago: https://github.com/ziglang/zig/issues/7295#issuecomment-7389...
Unless it's actually possible after all this time (even in some random beta) to do vector code in infix notation, it doesn't feel like it's going to happen :(
Zig won't ship with llvm as part of the standard download, but i imagine it will be easy to get zig+llvm working
a #everything_until_the_next_space b is rewritten in #everything_until_the_next_space(a,b)
So you'd have:
-a #foo b #foo c is foo(foo(a,b),c)
-a #foo b #bar c is forbidden, use parenthesis.
-and maybe #: for the inverse composition where a #:foo b #:foo c is foo(a, foo(b,c))
It's explicit, no hidden overloading, yet it's "short" enough to be usable: (a #* b) #+ c isn't that much worse than a*b+c and is much more readable than madd(mmul(a,b),c)..
If there is no implicit conversion name clashes shouldn't be too bad (both #+ could be usable for matrix and for graphic libraries).
How is that different from say, a function call? A function may look like a single O(1) operation from the input/output/name, but actually do something much more complex. That seems like the same thing to me, and very common. (and frankly I'm not sure that could even be avoided)
Perhaps I'll rephrase how I understand the philosophy: if it's a function call, it should look like a function call. Operator overloading breaks that.
That said, this isn't my hill to die on.
Edit to clarify my final sentence there: I have zero interest in debating this any further. Pixelpoet, if you're going to be so fussy, go read Harvey and van der Hoeven and stop trying to win language fights, they're tedious.
The ask isn't for general operator overloading (I'm also in favour of not having that), rather just not stopping native algebraic type support at scalars; the C function atan2(y, x) basically just wants to give you the complex argument, for example. Really it would just do so much to unify and simplify everything, besides being able to write vector stuff in a sane way; if every rando has to write their own vector and complex number classes, I'm much less likely to vouch for its correctness.
[0] I've recently been looking into Karatsuba multiplication to reduce it from O(N^2) to O(N^1.58): https://en.wikipedia.org/wiki/Karatsuba_algorithm
https://en.wikipedia.org/wiki/Computational_complexity_of_ma...
You don't want to know what the innocent-looking `*` in this function compiles to:
fn square(num: u10000) u10000 {
return num * num;
}And yeah, I get that Add(Add(Add(a, b), Mul(c, 3)), d) is possible, but come on... imagine if you had to write your normal "a + b + c * 3 + d" with ints/floats like that! What's that, suddenly people care, but nobody cares if it's not their field...
Whatever, I will continue to look longingly at Zig for all the bits of C/C++ (and apparently Go, to try bring it back to the original topic) it solves, but missing the trivial and absolutely critical single feature to enable an entire class of performance-critical programming.
You don't need them as a built-in type to write a compiler. They're there because LLVM was the original backend and you essentially get them for free (in the sense that the backend code generation is already handled for you, so why not include them).
u10000 exists only because we want u3, u7, and u13 as builtin types.
u3, u7, and u13 are useful for embedded and systems programming.
Zig does have builtin vec2f, it is spelt @Vector(2, f32).
But that's a strained interpretation of complexity, and not very useful.