3 ms·

I'm not certain that Go is a great fit for this particular area. Others have mentioned generics, but I'd also worry that the lack of operator overloading is a

by rwj 8y ago

I'm not certain that Go is a great fit for this particular area. Others have mentioned generics, but I'd also worry that the lack of operator overloading is a weakness. There is a lot of Fortran out there, so operator overloading is not required, but I'd worry about the ergonomics of Go, especially given the strength of the other options.

stcredzero 8y ago
The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. What would be the disadvantage of using a syntactic preprocessor to accomplish the same thing? We have an API for parsing golang. What if there was a way of marking certain files to be parsed and re-written with function calls? It could be done with a file suffix, and this could be made fairly convenient.
- Merovius 8y ago
  > The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. I don't think this solves the issues. For example, I have yet to think of a way to overload `+` in a consistent and performant manner. E.g. think of `a += b` vs. `a = a + b`. Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) or you are overallocating in the common case.
  - stcredzero 8y ago
    Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) Geez. That's obnoxious. Why do we programmers do this to ourselves? or you are overallocating in the common case. I see. I was thinking along the lines of being able to use complex numbers with arithmetic operators, not along the lines of doing high performance crunching of floats.
pjmlp 8y ago
Fortran supports operator overloading since Fortran 90, so 4 language revisions ago.

by rwj 8y ago

stcredzero 8y ago

The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. What would be the disadvantage of using a syntactic preprocessor to accomplish the same thing? We have an API for parsing golang. What if there was a way of marking certain files to be parsed and re-written with function calls? It could be done with a file suffix, and this could be made fairly convenient.

Merovius 8y ago
> The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. I don't think this solves the issues. For example, I have yet to think of a way to overload `+` in a consistent and performant manner. E.g. think of `a += b` vs. `a = a + b`. Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) or you are overallocating in the common case.
- stcredzero 8y ago
  Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) Geez. That's obnoxious. Why do we programmers do this to ourselves? or you are overallocating in the common case. I see. I was thinking along the lines of being able to use complex numbers with arithmetic operators, not along the lines of doing high performance crunching of floats.

pjmlp 8y ago

Fortran supports operator overloading since Fortran 90, so 4 language revisions ago.