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.

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.

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.