I am in the target audience. I do want low level systems programming.

Saying "you don't want operator overloading" in such cases is a reductionist view of how systems programming should look.

▲

bunderbunder 2 days ago | parent | next [-]

I’ll admit I interpreted that “you” in pron’s sentence to be a colloquial “you” and not an imperative one. So, more of a statement of their own preference than a strong statement of how things should be.

The point is, it’s a tradeoff. With overloading, exactly which code executes on a specific line becomes a bit more implicit because it depends on extra information from the surrounding context: the types of the arguments.

That comes with the usual tradeoffs. On the one hand, you could argue that the compiler is taking care of it for you, which saves the programmer from having to manually deal with it, and removes some visual clutter from the code.

But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing needs to carry all that contextual information in their own head, too. For this programmer, it’s adding to the mental burden.

I don’t think it’s a coincidence that Kelley constantly brings up how Zig was inspired by difficulties writing a digital audio workstation with very hard real-time requirements. Part of what he’s doing there is giving a motivating case for why he wants to be an absolute control freak about, e.g., micro-managing exactly when memory is allocated and deallocated. That’s something only a subset of systems programmers need, because not all systems programming is dealing with things like hard real-time.

▲

Ygg2 2 days ago | parent [-]

> The point is, it’s a tradeoff. If it's a trade off it's highly squewed.

>But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing

Use LSP/IDE then ctrl+click operator. Boom. You see what it's executing.

Idea is to create abstraction that make it easier to operate on a more complex level. If you need that level of micro-managing just stick to assembly.

▲

pron a day ago | parent [-]

Neither operators nor overloading are abstractions, and they offer no operation at a higher level. An abstraction is something that creates an equivalence class among multiple implementations, and that's not the case here.

First, operators are clearly not an abstraction because they offer a 1-1 correspondence: Instead of `x + y` you write `plus(x, y)`. It's just a different notation.

Overloading also isn't an abstraction because, as you pointed out, the resolution is statically known, and again, there's a 1-1 relationship. Indeed, it's just name mangling. Instead of writing `plus_int_int(x, y)` you write `plus(x,y)` and the compiler adds the `int_int` for you.

There's no doubt operators and/or overloading have some convenience advantages, but there's also no doubt they have some disadvantages, which is why some languages disallow one or both, regardless of how high or low-level they are. But Zig also has some special reasons to prevent overloading, because the language is built around compile-time introspection. So you can have just a single `plus` for multiple types, but the static dispatch is explicitly controlled by the implementation of `plus`. This means that all resolution is always local or uses unique names.

I'm not saying you have to personally like it. Zig and Rust both aim at different preferences so that people may prefer one over the other. But there is no difference in expressivity (but there very much is between assembly or even C and either one of Zig or Rust). Rust, like C++, chooses to favour implicitness over explicitness, and Zig chooses the opposite. Both have pros and cons, and neither is universally superior to the other.

▲

Ygg2 a day ago | parent [-]

> Neither operators nor overloading are

Ok. Show me machine code for operator overloading. It's all abstraction. Assembly, LLIR, programming language.

Abstraction is all about collecting complexity and presenting a clearer interface.

	▲	pron a day ago \| parent [-]
		They don't add any abstraction or, if you will, they don't abstract over code that's not with operators and/or overloading. There is only ever a single correspondence. That operators don't add any expressive power is, I hope, easy to see, as they're just notation. That overloading doesn't add abstraction you can see from the fact that there is only one "implementation" of resolution at any call site (if there were more than one, then it wouldn't be static dispatch). Overloads offer shorthand, not abstraction. Another way to see what's abstraction and what's not is to think what you can change in one place in the program without changing another (because that's what abstraction offers: indifference to the different elements in the equivalence class it creates). But there is no change you can make in a program with overloads that will require fewer changes in a program without them.

▲

hitekker 2 days ago | parent | prev [-]

To be fair, the impression is that you want to do low level systems programming in Rust. It's a fine preference but it does put you in a different audience

▲

Ygg2 2 days ago | parent [-]

I'm doing it in Rust because it's the closest to my ideal language. Not saying Rust is ideal.

	▲	pron a day ago \| parent [-]
		This is fine, but surely you recognise that Rust is very far from an ideal language for many other people, because there are no universal rules here. There's nothing more obvious than the fact that every programming language aims for an audience with specific preferences and tastes who like it, while others, with different preferences and tastes don't like it. This is how programming languages work when there are no universals: they make choices that appeal to some but not others. For example, I find Rust a particularly unappealing language because it's too complicated as a high-level language (it elevates too many low-level details and offers poor abstraction compared to high-level languages) while offering me few advantages, and it's too complicated for a low-level language, as it favours implicitness where I want explicitness. Clearly, there are many people who think like me, and many people who don't, and that is as it should be. It's perfectly fine for you and others to like Rust so much - it appeals to your particular tastes - just as it's perfectly fine for me and others to dislike it, because I tend to like simpler, smaller, and more focused languages. This is why I prefer Java over C#, Clojure over Scala, Haskell over Idris, and TLA+ over Lean, while being aware that many have similar preferences and many others have the opposite ones. Your preferences, like mine, are all valid and all far from universal. No language even tries to have a universal appeal, and none comes close.