Why functional programming?

All this does not yet tell us why we want to invest time in learning about FP. The main benefits we hope to get from functional programming are as follows:

• More readable code
• Easier to understand and debug code
• Easier testing
• Fewer bugs
• Easier concurrency

These can be achieved by a relatively small set of FP features. To achieve more readable code, this can be done by writing code in a declarative way. Declarative programming will show us what is happening rather than how it is happening. Declarative code is often more concise than the imperative counterpart. Conciseness is not necessarily a benefit to code readability (remember the APL example previously?) but when applied correctly, it can be.

FP makes code easier to understand, debug, and test by preferring purity over impurity. When each function always creates a deterministic outcome, we can trust a function does only what it says. When you encounter a function called square(n int), we can be convinced that all the function does is square the input.

In addition, the state of the system is not changed. If we are working with structs and objects, it helps us guarantee that the values our object holds are not changed by functions that are operating on it. This reduces the cognitive overhead when reasoning about our programs.

Pure, immutable code makes code easier to test for the following reasons:

• The state of the system has no impact on our function – so we don’t have to mock the state when testing.
• A given function always returns the same output for a given input. This means we get predictable, deterministic functions.

I won’t be advocating for test-driven development or any such thing here, but I do believe testing is critical to writing good code. Or at least, to avoid being paged at 3 A.M. because a function started throwing unintelligible error codes at a user.

Hand in hand with more testable code, FP helps us write fewer bugs. This is perhaps hard to quantify, but the idea here is that without mutable states and with only predictable functions in our code, we’ll have fewer edge cases to think about. If the state is important to your program, you have to know, at each point in time, what the state of the system can be and how it influences the function you are writing. This gets complex fast.

Finally, FP will make writing concurrent code easier. Go is a pretty well-known language for its built-in concurrency features. Concurrency was part of Go from its inception and was not tacked on later as with some other mainstream languages. As a result, Go has pretty solid concurrent coding tools.

The way in which functional programming helps is that functions are deterministic and immutable. Thus, running the same function concurrently can never impact the result of another running function. If functions never depend on the state of the system, thread A can not invalidate the system’s state for thread B.

One thing I want to highlight again, as it is important, is that I don’t advocate sticking to pure FP in Go. Doing so will probably make your life, and that of your coworkers, harder than it has to be. Choose the right tool for the job – sometimes that will be objects, and sometimes that will be functions.