Sure. But doesn't it still lack autodiff, quaternions, etc?

Yes, there are definitely other use cases that Zig doesn't support (which some may view as a good or bad thing). I just wanted to respond to the comment about basic SIMD since the example was U8x32 and operator+, which Zig can do.

▲

Ygg2 2 days ago | parent [-]

Point wasn't about SIMD, but defining my wrapper for it and giving it operations I needed.

Which seems to be something Zig can't do.

Hell, you can define operators for generic length SIMD lane.

▲

pron 2 days ago | parent [-]

It's not that Zig can't do it; Zig has been carefully designed to prevent it from being done as one of its core values, which is something that's important to some people just as the ability to do it is important to some other people. Supporting it or preventing it both have pros and cons for different users and different uses.

▲

Ygg2 a day ago | parent [-]

Sure Zig is pre-1.0 it can do anything but it's not going to do anything (e.g. add a borrow checker that closes the possible memory unsafety issues. They will add a runtime checker via Fil-C though)

The issue is the mindset, "I (Zig creator) don't need it nobody else does."

▲

pron a day ago | parent [-]

That's not what I wrote. I said Zig is carefully designed to disallow overloading because that's what some of us want (and there are Zig-specific reasons to want that even more). You, however, seem to be of the mindset that if some set of people want a feature, every language should have it, but that is clearly untrue. Something many of us value (especially in low-level programming, but not just there) is simplicity, which is the one feature you can never add to a language once you lose it. In every product, including programming languages, what features you don't allow in is just as important as the features you have. What made the iPhone the iPhone wasn't that it had a touchscreen, but that it didn't have a physical keypad.

In the case of Zig this is especially glaring and a core aspect of its design. In my low-level work, partial evaluation (or "compile-time code generation") is very important, and both C++ and Rust have it, albeit inelegantly. The problem is that they both bring with them the complexity I try to avoid. Zig is special because it offers all that power in a simple language, which is what many people want.

Different programmers want contradictory things out of programming languages, and it's impossible to satisfy all of them. Some people want to use a language with operator overloading, while others want to use a language that doesn't offer operator overloading. They can't be using the same language.

▲

Ygg2 a day ago | parent [-]

> Something many of us value is simplicity

Simplicity is a good metric but a lousy goal. If simplicity was a good goal, Brainfuck dialect would be the most used language.

> Different programmers want contradictory things out of programming languages

True to an extent but there are universal qualities every good language shares.

Ease of use; good performance even in naive cases; good safety/security even in naive cases; expressivity; fast compile times; conciseness.

	▲	pron a day ago \| parent [-]
		> Simplicity is a good metric but a lousy goal. If simplicity was a good goal, Brainfuck dialect would be the most used language. No, because simplicity is not the only goal. > True to an extent but there are universal qualities every good language shares. Yes, there are some, but none of them are relevant here. > Ease of use; good performance even in naive cases; good safety/security even in naive cases; expressivity; fast compile times; conciseness. Obviously, conciseness is not some ultimate goal, but a tradeoff, often one that contrasts with readability/understandability. APL is probably the language most famous for its conciseness, but it was never very popular. The same goes for some of the others: these are all good things but come with the caveat of "all else being equal", i.e. if two languages were identical in every respect but one was clearly better on one of these fronts it could be universally recognised as superior. This rarely happens, and usually to gain more points in some areas a language has to sacrifice others. Even safety is not as simple as it may seem. I've worked in formal methods and on safety-critical software, correctness is very important to me, and safety serves correctness. As you may know, while both safe Rust and safe Zig offer spatial memory safety, unlike Rust, Zig doesn't offer temporal memory safety. You'd think that someone who cares so much about correctness would always prefer more safety, but again we run into the problem of "... all things being equal," and that's not the case here. For one, to achieve its temporal memory safety, Rust sacrifices simplicity and explicitness, which are also important for correctness in some important situations (while Zig compensates not only in simplicity and explicitness, but also in other ways). For another, Rust makes you give up much of its safety precisely when you reach for a low-level language, which is when you want precise control. So the point is that things aren't so black-and-white (even Rust accepts that; e.g. there are languages safer than Rust, some existed before it was invented). Anyway, you will simply need to accept that even among the best and most experienced language designers in the world and even among the best and most experienced programmers in the world, there's often a lack of consensus, and in this particular case, some prefer Zig to Rust and some vice versa. They're both decent, they're both interesting, they're different from each other and make different choices when there's no universal superiority, and they're both liked by some and disliked by others.