>The thing is that GO was designed to replace c++ thing that absolutely failed.
I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present.
The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in C++, especially since I do lot of high-performance scientific computing. Overloading operators makes code a lot more readable and user friendly, in my opinion (I'm others will disagree, though). I'm aware that you can hack GO to mimic operator overloading but it involves hitting the vtable. And hitting the vtable is completely unacceptable in performance-critical code.
I wrote this analysis [1] in the context of Julia vs. C++ about why I think that Go has not been successful as a C++ replacement. The primary issues are performance (the ability to trade off abstraction for performance, really), generics, and operator overloading. We did not intend for Julia to be a C++ replacement, but it turns out that it's quite a good one and a lot of adopters have come from C++ – I think that these features are why.
Go is also easy to parse, AFAICT, both syntactically and semantically, and they ship a parser in the standard library.
While absolutely not implying that it's a reasonable alternative, someone could try implementing infix operators as a syntactic layer on top of Go (kind of a preprocessor). It might work to fix the use case presented in the OP (math operators being far more readable in their infix form).
Infix operators might just be implemented as a syntactic sugar layer after all, at least as a first draft; if you're able to parse a Go source file and its types in a way that when you see a sum expression, you already know whether both arguments implement a Numeric interface and/or Add method, you might be halfway through.
To clarify: I love infix operators and I'd love if Go added them, and I consider the above just a hack.
> Overloading operators makes code a lot more readable and user friendly,
Completely true for scientific computing, but I've been subjected to libraries written in scala recently and operator overloading there has lead to some very difficult to read and use libraries.
The key to preventing overloading of definitions from being a complete disaster is to be very careful not to overload meanings. I.e. if you're going to have lots of methods for your `frob` function, you had better be crystal clear what it means to `frob` something and only add methods that fit that definition. Scala and C++ libraries tend to like to just pick a random operator and use it to mean some arbitrary made up thing because they feel like it, ignoring the meaning of the operator. The classic example in C++ is using << for stream output. That's the left shift operator for Pete's sake! Why would that be what you use print stuff? Because you liked the look of it? It's not terribly surprising that this a complete usability disaster.
I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present.
The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in C++, especially since I do lot of high-performance scientific computing. Overloading operators makes code a lot more readable and user friendly, in my opinion (I'm others will disagree, though). I'm aware that you can hack GO to mimic operator overloading but it involves hitting the vtable. And hitting the vtable is completely unacceptable in performance-critical code.