The supposedly bad example is perfectly readable to anyone familiar with Go. A bit of refactoring into first class functions, and you'd have an easy to read, idiomatic, easy to test, well typed code base with obvious places to adjust useful behaviors like concurrency limits.
I like how he kept "tabs" (and display it as 9 spaces) to make it as ugly as possible for the bad example, then proceed to use 4 spaces for the other examples.
I suspect this is substacks default styling. It actually doesn’t set the tab-size which defaults to 8. However there seems to be some funky font-rendering going on so it adds an extra half (or maybe three-quarters) of a space per tab-character.
You can see this your self if you edit the markup in your browser’s inspector and add `contenteditable` attribute to the surrounding <pre>, then navigate down a line... it will jump forward just by slightly less then a column per indent level.
I'm well aware of it. But I don't think I have ever seen an editor/website which would display it as 9 spaces. Github for example default to 4 spaces width.
Yes, this is very weird. But Go Playground[1] has always been using 8 spaces per tab for some reason. I always found that very jarring, particularly where almost every other editor or documentation has settled on 4 spaces per tab.
I’ve come to believe that a direct implementation of something in the language is, where possible, more readable and maintainable in the long term.
Libraries that enable terse seemingly magical things tend to just hide a lot and make code harder to read. You end up having to become an expert in what amounts to a DSL on top of the language.
Meanwhile the samber/ro example is incomplete (Subscribe(...)?), and the source includes some weird stuff: https://github.com/samber/ro/blob/22b84c8296c01c4085e8913944...
Not to mention heaps of reflection and panics: https://github.com/samber/ro/blob/22b84c8296c01c4085e8913944...
The functionality and expressiveness might be fantastic, but I would evaluate it very carefully before use.