The article gives some examples about Go, and lists interfaces as something you should use, because the performance cost is tiny.
As someone who was formerly involved with the canonical Go style, I wanna clear up the reason why we said you shouldn't overuse interfaces. It has nothing to do with performance. (The difference between a "virtual" and "static" dispatch is not worth thinking about in Go.) It has everything to do with readability.
If you return an interface, I can't figure out what happens when I call it. That's fine with something like io.Writer, because it's a good abstraction and, anyway, I can guess. But hiding business logic behind an interface is bad, because I usually should understand what happens when I do something like foo.IssueReceipt(), and if foo is an interface, then I can't really know.
The rule in Go has for a long time been "return concrete values, accept interfaces" for precisely this reason.
Another relevant soundbite is that Go interfaces are an "accept-side" construct, unlike Java's, which are a "declare-side" construct. This is a way of saying you shouldn't define an interface near its implementation, you should define it near where it's accepted.
You might notice that this makes it really hard to do dependency injection in Go, and this, too, is intentional.
> Now that Go has yield, you can avoid using channels even more.
I’m very confused by this statement. To my knowledge, and after a good 5 minutes search, go does not, in fact, have yield.
Almost looks like an AI hallucination.
edit: the post itself is tagged with “ai” while its content doesn’t mention AI at all. To me this gives credit to my theory this is an AI hallucination and this post was in part or totally generated by AI. While I’m amazed by and excited about AI, this kind of generated content makes me worried it really will contribute to the fast enshittification of the Internet.
One thing I have noticed that a lot of devs don't know what a profiler is and even less know how to use it. They also don't have log files that would allow analyzing where the code spends most of its time.
Telling people to "strive for balance" sounds wise but never really lands, because humans are inherently unbalanced in our desires. Everyone has different priorities.
And another person finds premature Optimisation. From https://wiki.c2.com/?PrematureOptimization
Premature optimization is the root of all evil -- DonaldKnuth
In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal.
> "As creators of software and websites, we often get caught up in the never-ending pursuit of optimization. We constantly strive to make our code more efficient, our algorithms faster, and our page load times shorter."
I really wish this "problem" was more common!