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.

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.

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.

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.

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

or this: https://github.com/Knetic/govaluate

Elixir's function composition operator is |>

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.

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.

Functions, especially functions like numerical operations, tend to get trivially inlined and consume no stack space.

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 or alternatively https://github.com/facebook/starlark-rust

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...

Is this something Go intentionally didn't add?

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.

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.

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.

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

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.