At any rate, I feel like the goalposts have been moved a bit. You originally said:

But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway

Which I just wanted to point out that you can fuse these operations with operator overloading as well. I am pretty sure that

or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc.

was a later edit, I don't remember reading it when I first reacted to your comment. If so, doing that is not really nice, since it breaks the flow of the reactions.

At any rate, I think we agree on all the trade-offs.

And typing the multiplication operator in HN syntax sucks :).

> or you'll overengineer a complex solution to make AB return some kind of object that can recognize the subsequent + operation etc.

> was a later edit, I don't remember reading it when I first reacted to your comment. If so, doing that is not really nice, since it breaks the flow of the reactions.

I'm honestly not even sure. I had this in mind from the beginning, but I may have initially had a different vaguer comment about it and edited, I'm not sure. I sometimes edit comments right after posting them and then don't leave a note like I did for the later edit of the *s, since I assume no one read them. If this happened, I apologize.

Either way, yes, I think we are mostly in agreement. I'm not actually a big fan of Go's minimalism, so I actually see the value of such constructs.