I'm aware of this, however there is a pretty serious downside: function decorators (currying, whatever you want to call it) become difficult if type information

I'm aware of this, however there is a pretty serious downside: function decorators (currying, whatever you want to call it) become difficult if type information is encoded in the function signature. For example, I mark handlers for logged in users by: handle(..., User(F)) The prototype of F and User might be func F(w http.ResponseWriter, r *http.Request, s *Session, i interface{}) func User(...type of F...) func (http.ResponeWriter, r *http.Request, i interface{}) User() would do some preprocessing on the request and produce a Session for F. The problem is that User accepts ...type of F...; although it could accept an interface (of a function) but doing everything by reflection becomes cumbersome. This is one of the things I don't like about go but really you need a type system like haskell's to achieve what I want here.