Not that this is a good faith summary, but I've updated the article to point out that it's not just "this random 7-star library", but in fact, 266 publicly-available Go packages.
Your rant largely has to do with a library someone wrote that did not handle dependencies well. A few years ago you would have complained about lack of module support at all. I have a toy project that's relatively simple, and the Javascript frontend has a lockfile that is literally over 10000 lines long.
I was already shipping Go code a few years ago, and the various vendoring tools gave me a lot less grief the new module system has. Besides, it still had all the same limitations, the same standard library choices, the same sloppy abstractions. The rant applied then and it applies now - and focuses not on any specific problem outlined in the article, but the general philosophy of the language, its standard library, and its ecosystem.
> Your rant largely has to do with a library someone wrote that did not handle dependencies well
I am rather curious about how you concluded that "lots of dependencies bad" was the point of that section of the article and not, perhaps, the absurdity of having to compile an empty file to get around the solution to a bug being hidden from end developers.
- I don't like the file-related packages
- What's up with this random 7 star library having a lot of transitive dependencies
- Rust for life
- In summation, Go is the worst