This conclusion is dubious at best based on Go’s poor reflection performance. Most people coding in Go for any significant amount of time know this. Those reading this blog should definitely take time to research why you should never do what this blog advocates, like ever. In fact, in most cases doing so would get you fired if discovered.
Also, it is completely ill-advised to change the syntax of Go just because. Go’s mantra is simplicity and creating under-performing replacements for Python operator overloading is not only a horrible idea, it might be enough to get Rob Pike to hunt you down in person, hold you squarely by the shoulders, stare into your eyes, and ask, “WHYYYYY!?” Using
goto is more idiomatic in Go that what is presented here (and yes
goto has plenty of solid use cases, just look at any of the PEG output).
Another thing Go programmers should never do is apply the map/filter/reduce approach. Research why on your own.
The important thing to take away from this is that all languages are different and usually forcing a hybrid language to look like an academic functional language is bad idea. Altering a language’s syntax through reflection in Go is just plain foolish. I’m sorry you wasted your time reading this article. But at least you will now consider reading about idioms and best practices from industry experts instead of random, academic Medium bloggers with very little demonstrable experience coding in the language.