4 ms·

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something

• gcau 2y ago
  Is this something Go intentionally didn't add?
  • sbhitz 2y ago
    https://go.dev/doc/faq#overloading https://go.dev/doc/faq#overloading
  • jagged-chisel 2y ago
    Yes. Because "things are simpler without it." Presumably "simpler" from the point of view of the language implementer as opposed to the user of the language.
  • abtinf 2y ago
    Operator overloading essentially makes code unreadable without deep diving past the interface boundary. In Go, you can generally look at any snippet of code and know precisely what it does.
    • dsfasfd 2y ago
      Not having operator overload making the code more readable is the same argument that was brought up with generics and it is still false. Go does have operator overloading, for example + is overloaded for float.., int.. and even non numeric types like string. And it does so for a very good reason: having operator overloading makes code much more readable when used correctly. It's just that the language designers didn't trust their users. As long as you know the types of x and y you always know precisely what x + y does, same as you know what x.Add(y) does. There's no difference.
      • vincentkriek 2y ago
        There is no difference to a .Add() function, that's true but even for strings you wouldn't have an Add function. It would be an Append() most likely which explains much more what is happening. And verbosity helps, forcing users verbosity helps the general level of quality. Programmers could overestimate themselves and think they are doing it correctly. Looking back in my code from a year ago I see things I should have done differently. I like languages that avoid me making real dumb mistakes
    • xigoi 2y ago
      How is a + b any less “know precisely what it does” than a.add(b)? It’s literally just different syntax for the same thing.
      • deleted 2y ago
        [deleted]
• hello_computer 2y ago
  Something like Elixir's function composition operator (->) would go a long way toward smoothing that out, but they rejected that as well. I think the best we can do at the moment is runtime expression evaluation with something like this: https://github.com/expr-lang/expr https://github.com/expr-lang/expr or this: https://github.com/Knetic/govaluate https://github.com/Knetic/govaluate
  • dudeinjapan 2y ago
    Elixir's function composition operator is |>
• SatvikBeri 2y ago
  We switched from Python to Julia for numeric code. It's generally much faster (and easier to optimize), and has slightly better syntax for mathy code. It's worth noting that Julia is very similar to go, despite superficial differences. They're both small languages with big libraries, use the same concurrency model, use a mark-and-sweep GC with an emphasis on making it easy for the programmer to reduce garbage/allocations, and both use structs + functions rather than classes.
  • blt 2y ago
    Julia looks like a great language, but has the "time to first plot" issue been fixed yet? I don't want a REPL-centric workflow.
    • SatvikBeri 2y ago
      It's vastly faster than it was before (~5s compared to ~40s for the Plots package, and much less for most workflows) but it can never drop to 0, since it's compiling each function the first time you use it. Though honestly if you don't want a REPL or notebook-centric workflow, I would probably recommend a different language.
• dilyevsky 2y ago
  Numerical programs seems like a great fit for DSLs, say Starlark[0] ;-) That's what many C++ libs basically achieve with their heavy use of overloading, tmp, etc [0] - https://github.com/google/starlark-go https://github.com/google/starlark-go or alternatively https://github.com/facebook/starlark-rust https://github.com/facebook/starlark-rust
  • aragilar 2y ago
    But why would someone use a new DSL, vs an existing (general-purpose-ish) language that supports numerics (there are enough out there, e.g. R, Python, or the numerous paid ones like matlab, mathematica or IDL)? You have no ecosystem, plus now you're got to wrap 50+ years of numerical libraries...
• amedvednikov 2y ago
  [flagged]
  • IshKebab 2y ago
    Gotta admire the craziness of sticking with a language and apparently even building a community of fans even after such an insanely panned debut. I wonder if this will be the No Man's Sky of languages. Does it actually work yet?
• bouncycastle 2y ago
  in my case, I prefer to see that the code is calling functions, so that I'm aware that they take extra resources such as stack space and it's easy to quickly jump into the functions to find what they are doing. Code that uses op overloading is hard to navigate and sometimes causes intense debugging pain. Simplicity always beats fancy features imo.
  • stouset 2y ago
    Functions, especially functions like numerical operations, tend to get trivially inlined and consume no stack space.
  • blt 2y ago
    Operator overloading can be bad when abused for non-numeric types. But for numeric types, it is indispensable. It's not hard to remember that `__add__` is using extra resources when I'm working with big matrices in NumPy.
• tgv 2y ago
  In the same line of reasoning, Go also doesn't support getters/setters. You can't write v.a = 1 and expect it to call v.SetA(1). And that's a good thing. Cosmetically, because it avoids that all thickheads add a trivial get/set for each and every member. Functionally, because it can make code appear to do something it doesn't do, and this also goes for other operator overloading. I've worked on C# code where db.open was a test to check for a database connection, but assigning to it would open or close the database. It should simply not be possible to hide that behind an assignment symbol. It's like having db.Query(...) delete the data.