This seems to me, despite being cool, like the exact type of “too clever by half” code that Go was explicitly designed to avoid.
I like Go because most code is (if a bit verbose) not written like this. It’s written as if the person reading it is a little sleep deprived or one drink in - it doesn’t require much brainpower to reason about.
Adding methods that return functions that return closures is the kind of thinking with portals that I need to rev up my brain to be able to debug, and that’s a liability when there are deadlines involved.
> code that Go was explicitly designed to avoid
The post doesn't make it very easy to find, but it was written by Rob Pike, who was one of the designers of Go. So that arguably means that Go was designed to write code like this, although I do agree with you that the code is perhaps a little too clever.
Wow, good catch!
You have to know why the rules are needed in the first place to dedicate a big chunk of your adult life to making and maintaining a language that discourages breaking them, I suppose. It’s certainly an elegant api from the caller’s perspective, I’d just hate to have to maintain it.
The code being so complex as to have been written by the foremost authority on how to use the language to its maximum extent is another data point, though. Perhaps the KISS of Go is more of a cultural artifact of its corporate roots, though I like to think the explicit rejection of memory management, inheritance, exceptions, and macros (from pre-1.0) says otherwise.