Motivation for using FP
The FP style of programming can help you write less code in a more concise and expressive way, with fewer errors. How is that possible? Well, FP treats computation as an evaluation of mathematical functions. FP leverages this computational model (and the work of some brilliant mathematicians and logicians) to enable optimizations and performance gains that are simply not possible using traditional imperative coding techniques.
Developing software is not easy. You must handle numerous non-functional requirements (NFRs) first, such as:
- Complexity
- Extensibility
- Maintainability
- Reliability
- Concurrency
- Scalability
Software is becoming more and more complex. What is the average number of third-party dependencies in your typical application? What did that look like 5 years ago? Our applications often must integrate with other services within our own company and with our partners as well as external customers. How can we manage this growing complexity?
Applications used to run on-site on servers that were given pet names, such as Apollo, Gemini, and so on. It seems like every client would have a different naming scheme. Nowadays, most applications are deploying into a cloud environment, for example, AWS or the Google Cloud Platform. Do you have a lot of software applications that run on a lot of servers? If so, you should treat your servers more like cattle; there's just so many of them. Also, since you've got auto scaling, what's important is not a single server but the herd. As long as you always have at least one server in your cluster running for the accounting department, that's all that really matters.
With numbers comes complexity. Can you compose your applications to fit together like Lego blocks, and do you find it easy to write useful tests that run really fast. Alternatively, do you ever feel like there's too much scaffolding/for loops in your code? Do you like handling the err != nil condition so frequently? Would you like to see a simpler, cleaner way to do the same thing? Do your applications have any global variables? Do you have code in place to always properly manage its state and prevent all the possible side effects? Have race conditions ever been a problem?
Are you aware of all the possible error conditions in your applications, and do you have code in place to handle them? Can you look at the function signature of any function in your code and immediately have an intuition as to what it does?
Are you interested in learning about a better way to achieve your NFRs and enjoy developing Go software even more than you do right now? Looking for the silver bullet? If so, please continue reading.
Note that the rest of this book will be written in first person plural since we will be learning together.