6 ms·

Maybe an unpopular opinion among Zig programmers, but the lack of operator overloading is/was the true buzzkill for me as someone that tends to do a lot of math

Maybe an unpopular opinion among Zig programmers, but the lack of operator overloading is/was the true buzzkill for me as someone that tends to do a lot of math/science work in C and C++ both. Getting operators in C++ is one of the biggest productivity boosts compared to when I work in C.

vanderZwan 6y ago
I think it's fine to say why Zig doesn't work for you as long as you make it clear what the limitation is and why, and don't use that as an argument to say it's a bad language - just a bad fit for your particular use-case. Out of curiosity, aren't there other languages designed with more appropriate expressiveness for your needs then? Julia, for example?
- banachtarski 6y ago
  C++ is actually the sweet spot for expressiveness and complete control needed for the work I do on consoles and embedded devices. I was excited for zig because in many respects it really does feel like a better C, but I think philosophically, it’s more oriented around building particular types of systems. Disclaimer, I’ve sunk only about 35 hours into Zig so it’s possible it would be different with more experience but that’s about all the time I can realistically afford for a trial run of a new technology these days.
  - meheleventyone 6y ago
    Personally having done a bunch of mathy things both ways you get used to expressing thing without overloading. On balance I would opt for overloading because it feels natural to me but it’s a niggle rather than anything serious.
olodus 6y ago
I can understand the annoying part of it if that is the way you would do it elsewhere. Don't you feel that it would to some degree go against zig's goal of as little hidden control flow as possible? And wouldn't it be possible to create something very close to what you are asking for with a bit of comptime coding? Have the function work on a comptime decided type. I mean I get that you won't be able to use the operator symbols as names and you would lose infix syntax. Is those what you are after?
- banachtarski 6y ago
  I don’t understand that goal I think is the issue. I have no issues with understanding control flow with just... functions and operators? Sure you can’t glean it from a glance at the textual representation of code you aren’t familiar with, but day to day that’s literally never a problem. We have tools for that. A control flow problem worth solving is understanding async and multithtreaded code. And yes the expressiveness of actual infix operators is, to me, a strict requirement. The language is for humans, not machines after all, and stuff like add(mul(add(a, b), mul(a, c))) for, say, dual quaternion a, b, and c is a non starter. Most of my code would unfortunately become unreadable and there are often no sensible variable names for those intermediate results.
matheusmoreira 6y ago
Operator overloading leads to a complex binary interface. Avoiding complexity in this area is important given that simple binary interface is a huge reason why reusable software is still written in C. https://youtu.be/Gv2I7qTux7g?t=2m https://youtu.be/Gv2I7qTux7g?t=2m
- asdfasgasdgasdg 6y ago
  I'm puzzled. Operators in C++ are just function calls. How do they lead to a complicated binary interface? I only watched three minutes of the video but he doesn't talk about operators during that period.
  - dnautics 6y ago
    Ok so (seriously), as an experiment, compile a c++ code file that overloads, say, "+" into a .so file (let's keep it to elf format then) and let us know what the "true" name of the corresponding function is by hexdumping the .so
    - asdfasgasdgasdg 6y ago
      Many non-extern C++ names are mangled in .so files, not just operators. I don't see how that affects the ABI (i.e. the calling conventions of the functions). It just means you need to use a library to demangle in order to call the correct function.
      - dnautics 6y ago
        Yes, and it is a choice to not support any of them due to complexity. And as a result, you don't get operator overloading. Zig supports C ABI, not C++ ABI.
        asdfasgasdgasdg 6y ago
        You are confused. Supporting the C ABI and operator overloading are orthogonal. One is about conventions for saving registers and such. The other is about the naming of functions. Zig probably has a principled reason to not support operator customization, but ABI concerns aren't it.
networkimprov 6y ago
This is a good point. The right way to do this is to support arithmetic operators for types that implement a specific interface.
deleted 6y ago
[deleted]
nemo1618 6y ago
Part of Zig's core philosophy is that you can readily assess the "cost" of any particular expression is doing. There are no hidden function calls. If an expression doesn't contain (), you can be completely confident that it's not jumping away to some other piece of code. btw, I know it's not as nice as first-class operator overloading, but Zig's comptime might enable writing DSLs for e.g. vector/matrix math: https://www.reddit.com/r/Zig/comments/g83h12/comment/foleoa8 https://www.reddit.com/r/Zig/comments/g83h12/comment/foleoa8
- banachtarski 6y ago
  Comptime is certainly nice but not usable in this context I’m afraid. Also I’ve heard that argument a ton. It’s total complete rubbish as far as I’m concerned. Extrapolating, if you see a function call, what really can you say about the “cost” of that function? To me, without actual investigation, the answer is zilch. The function might be inlined, in the i-cache, referencing a lazily loaded symbol. It might be a small function, it might be huge, it may flush the cache, idk. If the goal was to be able to estimate the performance at a glance, well, we should use assembly, and even then the performance isn’t always clear.

vanderZwan 6y ago

I think it's fine to say why Zig doesn't work for you as long as you make it clear what the limitation is and why, and don't use that as an argument to say it's a bad language - just a bad fit for your particular use-case. Out of curiosity, aren't there other languages designed with more appropriate expressiveness for your needs then? Julia, for example?

banachtarski 6y ago
C++ is actually the sweet spot for expressiveness and complete control needed for the work I do on consoles and embedded devices. I was excited for zig because in many respects it really does feel like a better C, but I think philosophically, it’s more oriented around building particular types of systems. Disclaimer, I’ve sunk only about 35 hours into Zig so it’s possible it would be different with more experience but that’s about all the time I can realistically afford for a trial run of a new technology these days.
- meheleventyone 6y ago
  Personally having done a bunch of mathy things both ways you get used to expressing thing without overloading. On balance I would opt for overloading because it feels natural to me but it’s a niggle rather than anything serious.

olodus 6y ago

I can understand the annoying part of it if that is the way you would do it elsewhere. Don't you feel that it would to some degree go against zig's goal of as little hidden control flow as possible? And wouldn't it be possible to create something very close to what you are asking for with a bit of comptime coding? Have the function work on a comptime decided type. I mean I get that you won't be able to use the operator symbols as names and you would lose infix syntax. Is those what you are after?

banachtarski 6y ago
I don’t understand that goal I think is the issue. I have no issues with understanding control flow with just... functions and operators? Sure you can’t glean it from a glance at the textual representation of code you aren’t familiar with, but day to day that’s literally never a problem. We have tools for that. A control flow problem worth solving is understanding async and multithtreaded code. And yes the expressiveness of actual infix operators is, to me, a strict requirement. The language is for humans, not machines after all, and stuff like add(mul(add(a, b), mul(a, c))) for, say, dual quaternion a, b, and c is a non starter. Most of my code would unfortunately become unreadable and there are often no sensible variable names for those intermediate results.

matheusmoreira 6y ago

Operator overloading leads to a complex binary interface. Avoiding complexity in this area is important given that simple binary interface is a huge reason why reusable software is still written in C. https://youtu.be/Gv2I7qTux7g?t=2m https://youtu.be/Gv2I7qTux7g?t=2m

asdfasgasdgasdg 6y ago
I'm puzzled. Operators in C++ are just function calls. How do they lead to a complicated binary interface? I only watched three minutes of the video but he doesn't talk about operators during that period.
- dnautics 6y ago
  Ok so (seriously), as an experiment, compile a c++ code file that overloads, say, "+" into a .so file (let's keep it to elf format then) and let us know what the "true" name of the corresponding function is by hexdumping the .so
  - asdfasgasdgasdg 6y ago
    Many non-extern C++ names are mangled in .so files, not just operators. I don't see how that affects the ABI (i.e. the calling conventions of the functions). It just means you need to use a library to demangle in order to call the correct function.
    - dnautics 6y ago
      Yes, and it is a choice to not support any of them due to complexity. And as a result, you don't get operator overloading. Zig supports C ABI, not C++ ABI.
      - asdfasgasdgasdg 6y ago
        You are confused. Supporting the C ABI and operator overloading are orthogonal. One is about conventions for saving registers and such. The other is about the naming of functions. Zig probably has a principled reason to not support operator customization, but ABI concerns aren't it.

networkimprov 6y ago

This is a good point. The right way to do this is to support arithmetic operators for types that implement a specific interface.

deleted 6y ago

[deleted]

nemo1618 6y ago

Part of Zig's core philosophy is that you can readily assess the "cost" of any particular expression is doing. There are no hidden function calls. If an expression doesn't contain (), you can be completely confident that it's not jumping away to some other piece of code. btw, I know it's not as nice as first-class operator overloading, but Zig's comptime might enable writing DSLs for e.g. vector/matrix math: https://www.reddit.com/r/Zig/comments/g83h12/comment/foleoa8 https://www.reddit.com/r/Zig/comments/g83h12/comment/foleoa8

banachtarski 6y ago
Comptime is certainly nice but not usable in this context I’m afraid. Also I’ve heard that argument a ton. It’s total complete rubbish as far as I’m concerned. Extrapolating, if you see a function call, what really can you say about the “cost” of that function? To me, without actual investigation, the answer is zilch. The function might be inlined, in the i-cache, referencing a lazily loaded symbol. It might be a small function, it might be huge, it may flush the cache, idk. If the goal was to be able to estimate the performance at a glance, well, we should use assembly, and even then the performance isn’t always clear.