News for hackers. Stuff that matters.
Re:Zig's Curious Multi-Sequence for Loops by klyrs on Monday February 27, 2023 @12:38PM (#34959406)
Zig's "zip" is purely syntactical, where Python's zip is a generator. This is significant both in terms of performance (Zig wins) and flexibility (Python wins).

Unlike Python, you can't pass a zip generator around. It's just a for-loop. While zig loops are expressions, they only return a single value.

Re:Zig's Curious Multi-Sequence for Loops by masklinn on Monday February 27, 2023 @12:46PM (#34959511)
> This is significant both in terms of performance (Zig wins)

Does it, actually? Does Zig's built-in pseudo-zip outperform Rust's? Or C++23's?

> It's just a for-loop.

Except it's not "just" a for loop, it's a weird special case for a for loop. And one which is actively dangerous too.

Re:Zig's Curious Multi-Sequence for Loops by judofyr on Monday February 27, 2023 @01:08PM (#34959827)
> Except it's not "just" a for loop, it's a weird special case for a for loop.

You could also argue that a for loop which can only iterate over a _single_ sequence is a special case of a multi-sequence for loop.

> And one which is actively dangerous too.

In safe builds (ReleaseSafe, Debug) it will cause a controlled panic if the sequences are not of the same size. Most likely it's a logical bug if you iterate over two sequences of different sizes. In ReleaseFast the compiler will make assumptions to improve performance. If it's very important for your code you can force a certain code block to always have runtime safety. Yes, there are trade-offs, but I don't feel it's _unreasonable_.

Re:Zig's Curious Multi-Sequence for Loops by lmm on Monday February 27, 2023 @08:57PM (#34964721)
> You could also argue that a for loop which can only iterate over a _single_ sequence is a special case of a multi-sequence for loop.

When a "for loop" in virtually every language is not multi-sequence, not really. People expect a "for loop" to be a certain kind of thing.

Re:Zig's Curious Multi-Sequence for Loops by klyrs on Monday February 27, 2023 @12:56PM (#34959648)
Please check the context, I was comparing to Python. And please chill out. It's only "dangerous" when you decide to run it that way.
Re:Zig's Curious Multi-Sequence for Loops by masklinn on Monday February 27, 2023 @02:15PM (#34960645)
> Please check the context, I was comparing to Python.

Ah yes, that's very honest, no shit zig is faster than Python, what's the next one, thrustscc may be faster than polio-johnny down the road?

Re:Zig's Curious Multi-Sequence for Loops by klyrs on Monday February 27, 2023 @02:27PM (#34960763)
Hi, no need to be so abrasive about it.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Python's zip function returns a generator. A generator in zig would look like a function pointer with a closure. If zig were to implement the Python-style "zip" function, constructing the closure, and iterating over the generator, would be significantly slower than the naked "just a for loop" that we see in TFA. And that's not even considering the tuple construction (oops, now we need an allocator) & unpacking.

Ergo, the zig-style "syntactical zip" is higher performance than the Python-style "functional zip". Even when you cut through the baseline performance differences between the languages.

Re:Zig's Curious Multi-Sequence for Loops by masklinn on Monday February 27, 2023 @02:31PM (#34960816)
> Hi, no need to be so abrasive about it.

That's just projection.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

I'll get right on that as soon as you extend the same courtesy, which you have refused to do at every opportunity.

Re:Zig's Curious Multi-Sequence for Loops by pverghese on Monday February 27, 2023 @06:36PM (#34963623)
I'm assuming you like Rust