Yes, some people misuse the concept of currying in the wild. It really shouldn't be changed from its FP definition, because it is fundamentally different from partial application. Basically currying is only useful in Haskell. If you don't build it into your compiler as a first-class citizen you're going to be forever fighting a proliferation of closures in your generated code and then trying to optimize them back out. This is not a wise approach to language design.
Partial application is the better solution in imperative languages.
It is also not relevant to this discussion in the slightest, because the behavior of allocation and how those are passed into closures is independent of the question of how you spell those closures in code. You can easily build currying or some syntactic partial application into Go but leave this problem there, and you can easily fix this problem without building currying or partial application in.
This seems like a weird take. Currying was a completely natural thing to do in SML for example, why would it only be "useful" in Haskell ?
I agree that currying isn't likely to be the solution to any problem you have in say, Rust or Java. But "only useful in Haskell" jumped out as a weird claim.
Because SML is effectively dead and the only living language where it is useful is Haskell. It is not practical to discuss programming languages if one must include every dead language, every academic language every conceived of in some paper somewhere, every language sitting as a years-dead GitHub repo, etc.
Partial application is the better solution in imperative languages.
It is also not relevant to this discussion in the slightest, because the behavior of allocation and how those are passed into closures is independent of the question of how you spell those closures in code. You can easily build currying or some syntactic partial application into Go but leave this problem there, and you can easily fix this problem without building currying or partial application in.