Evaluate the use of functional programming patterns #3030
Replies: 6 comments
-
I've voted "yes" because I think it will come sooner or later. The adoption of FP is trending and I think we'll get more and more features (there are even proposals to implement a custom error monad). I'm not saying we need to rush to it, but I feel like at some point we will introduce some of these FP libraries to help make our code more readable, understandable and reduce boilerplate |
Beta Was this translation helpful? Give feedback.
-
I have mixed feeling about this one. I'll be ok to add it if these functions makes their way to the standard library, but I'm not comfortable with adding a dependency that changes so much our day to day work just for reducing simple for loops |
Beta Was this translation helpful? Give feedback.
-
I think we are mixing 2 different things. The usage of FP patterns doesn't imply new libraries (we can write our own code). We didn't include |
Beta Was this translation helpful? Give feedback.
-
Not sure in my opinion. In general if it is something that is beneficial for development then that is fine with me but I think we should also not fall into the necessity of having to adopt this paradigm for all cases. Maybe there will be cases that should follow a more imperative approach as Javi said, but there will be other cases where we can take into account this new feature of Go. If Go gives us the opportunity then let's take advantage of it but when it really adds value or at least does not reduce it. |
Beta Was this translation helpful? Give feedback.
-
I don't feel we need to focus right now on changing a paradigm. Also, i'm not fan of adopting "trending" new features without a deep evaluation. Our efforts, AFAIK, are going towards stability of CLI?. I think this should be part of a bigger conversation regarding technical debt, how to approach it, and how to evolve the CLI. |
Beta Was this translation helpful? Give feedback.
-
introducing generics and specifically "lo" would reduce boilerplate code that should have been addressed by go a long time ago: search algorithms, map, filter, set operations, etc' I've mapped some part of the cli codebase and saw many recurring patterns that "lo" can replace in one line. that makes the code smaller, less error prone and more importantly: less code to maintain. |
Beta Was this translation helpful? Give feedback.
-
There had been some attempts to introduce functional patterns into this repo in the past.
Most had been turned down due to 2 reasons:
go
As we adopt
go 1.18
and above, go provides generics. This combined with "functions as first class citizens" gives us a solid floor to make use of fp patterns.Describe the solution you'd like
Evaluate the introduction of external libraries like https://github.com/samber/lo to reduce boilerplate.
Describe alternatives you've considered
I think that as we keep developing with the latest go version, more and more features of fp will come to the language and start being "idiomatic". I know that generics will be a great addition to our toolkit in future PRs
Additional context
Last issue where this was mentioned
6 votes ·
Beta Was this translation helpful? Give feedback.
All reactions