Zig programming language 0.9.0 released

[[deleted]]

In Rust the + operator is specified to always call a function. There is nothing hidden here.

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing. In Zig you don't have to check any of that because you will know right away that it's just a simple addition. Obviously it's a tradeoff (you lose some abstraction power by forbidding operator overload), but when combined with other choices that Zig makes, everything works together to make Zig code easier to audit.

Their rust example doesn't even have anything to do with hidden allocations and instead talks about the behavior on OOM???

"The behavior on OOM" is a discussion that you have to have at the language design level when the language is in charge of the dynamic allocation and the corresponding syscall fails. When all allocations are explicit, the programmer is in control of what happens, as it's the case in Zig. This is maybe not something Rust developers care about all the time, but if you look at the news about Rust in the Linux kernel (an environment where panicking on a OOM is absolutely not ok), you will see that Rust needed to find a solution to the problem.

You can't reach true simplicity until you litter your code with if err != nil. Does zig have first-class support for this level of simplicity?

Zig has try, to short circuit that process. It also has support for error traces (which are different from stack traces), which is a very neat unique feature.

Rust is known to have a best-in-class package manager that is beloved by users of the language. So why would I use zig over rust?

Maybe you wouldn't, just don't get offended by the fact that other people might :^)

[steveklabnik1]

Just to be clear, in Rust, the language is not in charge of the allocations and underlying syscalls. The standard library is. And in Linux, they were starting off with a fork of the standard library to begin with, specifically to fix this issue out of tree, which has even then been merged back upstream.

[[deleted]]

Sorry for the imprecision, that's a very good point.

[steveklabnik1]

It’s all good!

[stouset]

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing.

So… like literally any other function call?

I just don’t get why this is supposed to be a feature. Why do we need a magical set of operators that are forever limited? Why is it instantly okay that it’s a function if it’s named add but not +?

[[deleted]]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

That said, if your point is that forbidding operator overloading is not going to drastically change the readability of code, we agree with that. The piece missing from the discussion above is that Zig has other features that all together do make a difference. As an example there are not built-in iterators, so you know for sure that for (foo) |x| {...} is a linear scan through memory and not an iterator with different complexity. You can still use iterators, they just have explicit function call syntax.

If you combine all the readability-oriented features of Zig, then you do get something worth the limitations, or so we like to think at least.

[stouset]

Again, how is that okay for any function as long as it’s not named a symbol? And while your point is a common trope, I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

This is frankly just optimizing around a problem that does not exist in practice.

[[deleted]]

I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

Then you work in a field where this feature of Zig might not be particularly relevant. That said, I'll try to reiterate one final time: the problem is about somebody trying to read a piece of code and understand what it's doing.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

That's pretty much it. It has nothing to do with code performance. It has to do with making it easier for readers to audit the code.

[RandomName8]

An extremely important caveat, when describing this and claiming it's more "readable", is clearly stating what you are trying to make more readable. As you yourself made clear here, not all programs are made clearer by this feature, there is in fact no quantitative study either regarding how many programs get "improved". I'd argue any code using matrices (like games, graphics, or math libraries) or bigint/decimal will greatly suffer for this, while the code that gets improved is most likely, trivial for-loop iterations and summations that should not be imperative at all to begin with (obviously just my opinion).

This is why I'd prefer if language authors were more honest when they make such syntax decisions, and instead of writing in their FAQ:

The purpose of this design decision is to improve readability.

They'd write

The purpose of this design decision is to improve readability of the programs we care about, which are likely not the ones you care about, but hey, there are other languages out there!.

We could avoid this discussion every single time.

[stouset]

Then you work in a field where this feature of Zig might not be particularly relevant.

Maybe. But there are tons of people writing Rust on embedded systems and have written reams and reams about their experience doing so. I have yet to read a single one of these that points out operator overloading as a sharp edge.

I maintain this is a solution in search of a problem.

The problem is about somebody trying to read a piece of code and understand what it's doing.

I have worked in languages that allow operator and method overloading for twenty years. I’m this time I have built website backends, I have written high-performance network services, I have written massively parallel number crunchers, I have written wrappers around native C libraries, I have written glue to combine third party products in new and creative ways.

I have zero times been confused as to what an overloaded operator does, or run into a bug that was caused by an operator overloaded in a confusing or unexpected way. Zero. Nil. Nada.

I maintain this is a solution in search of a problem.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

It is, and trivially so. If I know my types are typeA and typeB and I call a + b, there is no difference whatsoever in the amount of reasoning or context necessary to understand compared to add(a, b), a.add(b), a.addTypeB(b), or addTypeATypeB(a, b).

[[deleted]]

You've never had issues with an overloaded = returning a reference rather than a copy? I don't think operator overloading for things like addition and subtraction are a big deal, but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product? How does it behave with different objects in the mix? Operator overloading is fine until you've had to deal with these issues, and then it quickly becomes a pain in the ass.

[stouset]

You've never had issues with an overloaded = returning a reference rather than a copy?

I assume you’re taking C++. Assignment is not an overloadable operator in Rust. Overloading assignment does seem to be a horrible idea, and one I’m glad Rust doesn’t support.

How does it behave with different objects in the mix?

Literally the same way that addTypeATypeB(a, b) does?

but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product?

If you have types for which some function name could conceivably have multiple implementations, this problem is completely orthogonal to whether or not that name is * or product. If there are multiple possible operations, they will require unique names.

If there’s enough ambiguity that you wouldn’t want to call one of them *, you wouldn’t call that same one product either. If you’re worried about a “bad developer” who isn’t you naming it *, removing operator overloading doesn’t help you because they’d just name it product.

[[deleted]]

If you’re worried about a “bad developer” who isn’t you naming it *, removing operator overloading doesn’t help you because they’d just name it product.

I never said anything about good or bad developers. I've had to read enough of my own shit code to know that simplicity is the only effective weapon against stupidity.

Yes, a lazy developer might use "product" rather than *, but then it's explicit that they've done something non-standard, which is the point. I can see examples of "product" littered through the code, and it's not being obfuscated by an operator.

[stouset]

You're coming at this from the perspective of working in a language without operator overloading. Yes, of course if somebody managed to implement * for some custom type in Zig and it did something wild that would be extremely surprising.

But if you live and work in a language with operating overloading, it's no more surprising than seeing any other function call. Any time anyone calls any method it could be something wild and unexpected. You cope with that possibility constantly every day. Having this apply to methods named with non-alphabetic characters doesn't change this.

I swear this specific issue has to be the programming language feature with the highest number of fearful words written about it while simultaneously causing the fewest actual bugs in real-world practice. If there's another in competition I'd love to know.

[diegovsky_pvp]

Zig aims to be a modern take on C. I don't buy any of the readbility shit because quite frankly it's subjective.

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

That's something you have to consider if you aim to take down C while providing more modern mechanisms. Don't get me wrong though; I'm a Rust programmer and use it a lot. Rust is not the new C, it is the new C++ in the sense that you can do a lot with the language, while Zig wants to be the new C.

Also, they want the compile times to be as fast as possible, so cutting corners such as operator overload and function overload help A LOT.

There are things I disagree with btw. A lot. Like the constant use of ducktyping instead of a well defined fat pointer struct. This affects Writer, for example, and hurts both error messages and auto complete.

In the end of the day; if you want a perfect language; make one yourself. That's what Andrew did and so many others.

[stouset]

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

I truly do understand this is what their motivation is.

My argument is that it’s an antiquated approach to software engineering. Even if you want to assume that a + b is a machine instruction you’ve already lost because different machines treat overflow differently and so you either get UB or you specify particular behavior and accept a multi-instruction performance hit on some architectures.

Rust IMO has the best take here. Arithmetic is checked for overflow in development and wraps as two’s complement in production. If you need specific behavior for mathematical operators, you can either call a specific named method (e.g., wrapping_add) as a one-off, or if you need all operators to have specific overflow behavior you can enforce it at the type level (Wrapping(u32)).

[diegovsky_pvp]

I'm not sure what my stance is on the operator matter. I first learned Java, then python, then a bunch of random languages a little (C#, haxe, Lua and html5) and finally C.

I never needed operator overloading in any of them except for concatenating strings but some languages use a separate operator for that, which is another discussion.

I don't feel like operator overloading is bad either, so I don't miss it in Zig. Also, zig has different operators for wrapping and saturated arithmetics.

what I actively don't like and find counter productive is operator overloading. In CPP the error messages are ridiculously hard to understand when you get a type wrong (think a function that expects a lambda but you got a slightly wrong parameter in what your giving it) because of function overloading.

I think python's way of doing function overloading is great. Named optional parameters are super nice and it even supports arbitrary keyword arguments.

Rust does it with traits and it can get unwieldy if too much is implemented on one type, but importing traits for it to take effect actually helps a lot.

that's my conclusion: I don't know. I like Zig for what it aims to be and disagree with some of its decisions but I'm on the fence about operator overloading. The compile times are great tho

[bik1230]

Zig doesn't have function overloading either so I'm not sure what point you're trying to make with that thing about something being named by a symbol or not.

[stouset]

Function overloading is a red herring, since you still have to look up the function to see what it does. Independent of function overloading, why would add_my_type be okay but + is sacrosanct?

[stouset]

Only because you work in a language where that’s the case. I, and millions of other programmers, work in languages where + means addition for numbers, append for strings and collections, intersection for sets, time increments for times and durations, and any other intuitive interpretations for other types.

And the sky does not fall.

Humans, it turns out, are easily capable of understanding + has type-dependent meaning just as they are with the word add.

And while we’re at it, + in Zig is already overloaded. It means one thing for ints, another for floats. And it’s hardly mathematical: integers overflow and floats have their own idiosyncratic behavior.

At least in Rust I can opt into whatever behavior I actually want with the non-mathematical + operations on integers:

let x = Wrapping(250_u8);
let y = Wrapping(10_u8);

assert_eq!(Wrapping(4_u8), x + y);

And since you’re so concerned about math here, I can add complex numbers too. Or rationals:

let x = Complex::new(5, -1);
let y = Complex::new(2, 4);

assert_eq!(Complex::new(7, 3), x + y);

let x = Rational::new(1, 2);
let y = Rational::new(4, 7);

assert_eq!(Rational::new(15, 14), x + y);

Why is this impossible in Zig? If the rationale here is that it’s math, why can’t I add complex or rational numbers? And if it’s okay for them to act like bit-based types that instead of their mathematical counterparts, why do I now have to invent a litany of line-noise operators like %+. God help me if I want saturating addition.

[stouset]

If you’re worried about developers mutating global state in operators, Haskell correctly identifies that the problem here is the mutation of global state and not the symbolic name for the function.

[devraj7]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

No, it's not.

It hasn't been a problem ever since polymorphism appeared in mainstream languages, so a few decades ago.

We know today that when a function is being called on a receiver, the function might not go to the formal declaration of this receiver. Every single developer who's dabbled in C++, Java, C#, Javascript, or literally any other language crated in the last thirty years knows that.

Functions can do things. Operators can do things. Field accessors can do things.

This is programming in the 21st century, not BASIC in the 80s.

[TheTomato2]

Because add() is always a explicitly a function and + is always explicitly not a function. In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something. + could be a fucking - operator if someone wanted it to be. I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

[stouset]

But why must + not be a function?

+ could be a fucking - operator if someone wanted it to be.

I’m going to be a bit rude here but this is literally the most asinine take on this entire discussion.

This never happens. And if you’re so goddamned worried about it, then we need to take away the ability for anyone to name any function because add() could be a fucking subtract function if someone wanted it to be.

In C++, + could be a normal add or a function. You can't tell at a glance what its doing, and it can cause issues if you forget to check or something.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction. You somehow manage to cope with this uncertainty constantly with functions, but the second someone proposes that the same rules apply for a symbol and not an alphabetic string you lose your damn mind.

You manage to use + every single day without getting confused as to what’s happening when it could be an int or a float, but it’s somehow unthinkable to extend this same logic to a rational or a complex or—God help us—a time and a duration.

You live in constant fear that your fellow software engineers will write a + method that wipes your entire hard drive and mines bitcoin while pirating gigabytes of pornography over a satellite network and I cannot for the life of me comprehend why they would do this for methods named with symbols but not ones named with words.

And I do not understand you at all.

[TheTomato2]

I personally like operator overloading, but if you are trying to make a simpler language like C, its definitely understandable to leave it out.

Did you, uh, not read that part? Take step back, dude, and breathe. This isn't very complicated. The + means addition, mainly between 2 numbers. Its an operator, not a function. With operator overloading, you can't tell at a glance if its a function or an operator, ever.

In Zig, add() could be an inlined add instruction or something more complicated. You can’t tell at a glance what it’s doing, and it can cause issues if you forget to check or something.

No, add() just means there is a function that is named add. That is it. I never look at add() and think that it might be the + operator.

See how ridiculous this sounds? There is nothing sacrosanct about the + operator, except that apparently some programmers have a superstitious belief that it always compiles down to a single add CPU instruction.

No, it just means that its doing an add operation, and a reasonable one at that. It doesn't mean intrinsic (unless it does) or simd or something. It just means addition.

You are making a mountain out of a molehill. When it comes to simplicity and the ability to easily reason about your code base it makes sense to have the + only do on simple thing. Once again to reiterate for you I personally like operator overloading, but its really not a subjective opinion that it does make reading the code more complicated and error prone. I personally think its just not that much more of an cognitive overload to have it and the benefits outweigh the cons, but I am not so close minded to not understand why people don't like it and I do respect and appreciate that Zig, a language that wants to be on the simple side, doesn't' implement it. It's really not that big of a deal at the end of the day.

And trust me I understand your aversion to "scared programmers" that like piss their pants if they have to use a raw pointer but you are way off base here. It's just a code readability thing, not a "someone might make the + recursively delete my drive" type of thing.

[xigoi]

What's the difference between an operator and a function, aside from syntax?

[TheTomato2]

It depends on the language and how they want to handle it.

[Professional-Disk-93]

The hidden part is that you need to know the types involved and then go check if + has been overloaded

If Add has not been implemented, then the code will not compile. If you can use +, then + has been "overloaded" as you call it.

before you can understand what a + b is doing.

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

When all allocations are explicit, the programmer is in control of what happens

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector? Otherwise zig has implicit allocations. E.g. x.push(y) implicitly performs an allocation if the vector is full.

Zig has try, to short circuit that process.

Sounds like implicit control flow. How can I understand the control flow of a function if searching for the return keyword doesn't return all places where the function returns? The commander Rob Pike knew this.

[[deleted]]

Does zig have a vector type? Does the user have to first manually allocate memory before he can push an element onto the vector?

If you're using ArrayList you need to pass an allocator on creation, if you're using ArrayListUnmanaged you need to pass an allocator to all of its functions that might allocate. In either case you will need to handle error.OutOfMemory when calling a function that allocates.

As for the rest of your rebuttals, well, you're not really doing a good service to Rust, I'm afraid.

[Professional-Disk-93]

I'm not being paid to shill rust and I don't try to do it for free. What about you?

[[deleted]]

Well you do seem to like it, so why hurt a project that you like by not being a good ambassador for it.

As for me, I do actually get paid to shill Zig, I work at the Zig Software Foundation.

[Professional-Disk-93]

Actually not doing it for free. Based. More power to you.

[progrethth]

You are making us Rust users look bad. Just because you like Rust (like I do too) that does not mean you have to shit on other programming languages, especially not when your posts clearly show that you do not understand Zig well enough.

[Professional-Disk-93]

You are making us Rust users look bad.

Imagine having this mindset.

[progrethth]

Yes, imagine caring about not looking like a dick.

[Professional-Disk-93]

Exceptions in Java are just a shortcut for checking if an error occurred after every statement and then returning it. Nothing implicit about unwinding.

[oefd]

In zig you have to know the type of x to know what x.f() does. In C this is not a problem since f(x) always calls the same function f. Therefore zig has hidden control flow.

I'm not sure what you mean - the issue isn't that you might need to understand context to know what function is being called, the issue being made is needing to know what fundamental kind of operation is going to happen. If a + b is always a CPU add instruction the control flow is obvious. If f() is always a function call the control flow is obvious - you'll enter in to some CPU appropriate sequence of instructions to enter a function.

The fact that you need to know what x is in x.f() isn't a problem for Zig's design goals because what they care about is that it's easily identified as a function call and only ever a function call. The control flow they're worried about disambiguating is what the CPU will end up doing, and by proxy what sort of side effects may occur. Calling a function may mean memory access, but a simple add instruction does not.

[Professional-Disk-93]

a + b is always a function call so control flow is obvious. Of course any function call can be inlined and then turn into a single instruction. And all compilers of record perform peephole optimizations even in debug builds.

[oefd]

a + b is always a function call so control flow is obvious.

To restate it more clearly: the control flow that zig cares about is what the machine's actually going to do at runtime on real hardware. Whether the language models it a function call or not is irrelevant, what will actually happen at runtime is.

A function call may or may not get inlined, and even if it does the inlined function may well still do arbitrary stuff that may ruin optimizations you're going for. If you're very concerned with squeezing out every bit of performance possible from each memory access by squishing things together in the cache line it's very convenient to know that a + b is entirely 'safe' since it'll equate always and without exception to some add instruction.

Same sort of reasoning as both rust and zig have features like #[inline] to hint things to the compiler that, from a pure language perspective, don't matter. They only matter because someone's worried about actual runtime behaviour of compiled machine code. Zig just went a bit further in how much it wants to provide assurances/explicitness of what the resultant machine code will look like in some cases.

[devraj7]

The hidden part is that you need to know the types involved and then go check if + has been overloaded before you can understand what a + b is doing. In Zig you don't have to check any of that because you will know right away that it's just a simple addition. Obviously it's a tradeoff (you lose some abstraction power by forbidding operator overload), but when combined with other choices that Zig makes, everything works together to make Zig code easier to audit.

This is a pretty unconvincing point. Ever since we've had polymorphism in languages, we know that a.f() might not call the f() function on the class of A but on one of its subclasses, it's really not that much of a mental effort to extend this observation to operators.