You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I usually discourage the use of lambdas, but where are some situations when they really improve convenience for developers like time.AfterFunc(duration int, func()) or registering various handlers like: ch.Handle(conn.TopicInit, func(c conn.Context) error or famous type HandlerFunc func(ResponseWriter, *Request)
Lambas impairs the readability and traceability of a code in many cases, especially if the codebase is complex. IDEs also usually having trouble handling them properly, thus it might be hard to trace where certain lambda function originates from.
The text was updated successfully, but these errors were encountered:
Thanks for pointing out the error @zolia 🙇 I definitely agree. I think a lot of the time, the Go lambda is a crutch used for trying to deal with the lack of generics. I would also prefer avoiding them as much as possible, to be honest.
should be:
I usually discourage the use of lambdas, but where are some situations when they really improve convenience for developers like
time.AfterFunc(duration int, func())
or registering various handlers like:ch.Handle(conn.TopicInit, func(c conn.Context) error
or famoustype HandlerFunc func(ResponseWriter, *Request)
Lambas impairs the readability and traceability of a code in many cases, especially if the codebase is complex. IDEs also usually having trouble handling them properly, thus it might be hard to trace where certain lambda function originates from.
The text was updated successfully, but these errors were encountered: