Go is awesome, but

Since Go was not designed to be a pure functional language and lacks generics, we must take a performance hit to force Go into a functional style of programming, right? (Keep the faith! There's hope around the corner.)

We have covered the core principles of implementing and using collections. You learned that in functional programming, a single function can take input and return a result and transformations to the collection that occurs inside the function. You learned that we can compose functions by chaining them together.

If Go had generics that would simplify our implementation task, but more importantly, if Go were designed to perform tail-call optimization (TCO) and other performance-boosting optimizations, then it would be an easy decision to choose to program in the functional style in Go.

One of Go's best features is its performance, and if we are developing a solution that runs on a single server and performance is more important to us than having concise, intuitive, and declarative code, then most likely we would not program Go in the functional style.