I don't think so either. What he wrote was unclear (sorry, tptacek). I was clarifying what I'm pretty sure he meant. It's not like I've never done the same thing in writing myself.
"Also, this requirement effectively rules out ever using go in a repl. I think that is a minus for modern programming languages."
It's ruled out for a lot of other more fundamental reasons. Go is probably the most highly polished language from the 1980s.
This would be a much greater condemnation, except the sort of people who tend to frequent HN (including me!) tend to grotesquely overestimate how much most programmers are spending coming up to speed on the latest and greatest. In many contexts, a "really nicely polished 1980s language" is a step up in either reliability or speed. Perl is nominally a more advanced language, but on the whole, most programmers just use it as a sort of dynamically-typed C. I think the majority of programmers still aren't all that clear on what a "map" is. Arming my fellow programmers with more capabilities doesn't solve any problem either I or they have, but can make them worse.
Also, I'd observe that even for modern programming languages, "needs a REPL" is setting the bar high. Rust will probably never have a REPL. I see a couple of defunct projects trying and I haven't studied them, but at best Rust could have an all-in-unsafe REPL dialect, because who's going to be able to reliably type borrow-safe code into the REPL on the first try?
And thanks for the relativism in that remark about the most highly polished language from the 1980s. I fear you are right in that (example: today, a colleague said this was the first time he created a thread. He has had a job as a developer for a few years, and, given his age, likely never wrote for a CPU that isn't multi-core. Luckily, he isn't dumb, as he asked what would happen if that thread threw an exception)
I think ML pretty objectively takes that crown, semantically speaking. For simplicity and elegance it's pretty difficult to beat.
I don't think I misquoted the OP. He said "A and B help me with C" and I questioned how A could help with C, given the other claim that the OP doesn't pay any attention to A anymore.
"Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation breaks"
That is a problem with perl, a language whose 'grammar' is about as free-form as it gets (aside: iOS is funny at autocorrecting programming language names: cobol => cool, perl => peril or pearl, depending on context), but not with go. The compiler can generate errors for unused imports; it easily could generate warnings instead.
I like clean code, but I also like it if a quick experiment doesn't require extra tooling to remove imports to make things compile, more so if it is not guaranteed that undoing such changes can be automated (adding imports isn't 100% reliable; if it were, why have import statements at all?)
In summary: Go is too opiniated here for me.
Also, this requirement effectively rules out ever using go in a repl. I think that is a minus for modern programming languages.