I guess I don't get it. I agree the abstract idea that a simpler solution is usually preferable. But I don't see how this translates for a language like C++ or Go.
I understand the backlash against "magic," but this more a concern of "spooky action at a distance" rather than overhead.
Could somebody who understands the sentiment help articulate what type of solutions can be more easily expressed in Go than in say Scala (short of performance-centric cases? Or is this solely about performance-centric cases?).
The claim isn't that it helps specific things, but that the more detail work you have to do, the less attention you can pay in the large. This is why, for example, Go has the proverb "a little copying is better than a little dependency"; you make a downpayment in the small to make your architecture cleaner.
This is something C++ makes exceedingly difficult (Linus Torvald's famous rant is half on this topic). This is also something Scala doesn't do well at, opting to provide a lot of features that make bits of code "prettier" at the cost of being able to see what is being built.
I understand the backlash against "magic," but this more a concern of "spooky action at a distance" rather than overhead.
Could somebody who understands the sentiment help articulate what type of solutions can be more easily expressed in Go than in say Scala (short of performance-centric cases? Or is this solely about performance-centric cases?).