I bought this book a few months ago along with some Go books from O'Reilly, and Manning. I was probably the most excited about going through the content of this book but it has been, by far, the lowest quality of any of those books. It's probably the worst programming book I've purchased for any language. Let's get into why.The author chose to write this book in a very casual, approachable style. It's filled with memes and conversational diversions that, in an actual conversation, could be engaging and interesting. The target was probably a rip-off of the Head First series. It doesn't come close to that standard and it's instead like listening to someone who clearly knows what they're talking about but keeps coming up with different examples and abandoning the one they just started explaining. The text meanders all over the place, veering between different languages, math equations, and random memes and jokes before getting back (if ever) to the Go implementation of what's being discussed. For some people that may lead them to a deeper understanding of the core concept. For me I found it useless to traverse that much ground and abandon Go for different territories and implementations in other languages. The other books I've read stick to the Go realm, and then discuss whatever other world afterward. I personally find that much more useful and clear than half-assedly dealing with a concept in different languages one after the other. Especially when I don't know the other language (Haskell is used a lot since it's a pure FP language, and, if I knew Haskell I'd therefore already know FP and not necessarily need to read a book on how to do FP in Go).The book repeats itself over and over and over and over, which needlessly bloats the length. Specifically, the book continually harps on what Go would be like if it supported generics and TCO (tail-call optimization). As in almost every chapter. Sometimes multiple sections of a chapter. Usually In the middle of explaining a topic. That means that, instead of concisely grouping Go code and concept basics to a continuous section of pages, instead you'll thumb through interspersed pages to try and get all of the Go details together. It's hugely annoying. Also, spoiler alert, near the end of the book, after a lot of wasted pages in the previous chapters, the book states that changing Go to support these features would mean losing incremental compiling, which would slow down the fast compile times, and also require completely overhauling/re-writing the type system. So we then get the conclusion that it's not a good trade-off. Great. I cannot fathom why the previous chapters weren't then edited to cut out those sections, and maybe combined to have a single chapter that shows how Go would function with generics and TCO. It's like reading a high school essay that's graded by page count. I doubt the book was ever edited as a whole, so the end result is this strangely contradictory opinion on this one topic. It's a bit baffling to see good, DRY code examples in the text but not have those principles applied to the text itself.Another gripe: The book doesn't group compiling Go code together. Meaning, the author might be talking about some Monad implementation, for example, which calls a bunch of functions, but the code will only display some of those functions, or part of some functions and then not show the rest. So, instead of something like:func main() { type strFunc func() string out1 := "Hello, " out2 := func() strFunc { return func() string { return "World" } }() out3 := "!" fmt.Println(out1 + out2() + out3)}You might have:func main() { type strFunc func() string out1 := "Hello, " out2 := func() strFunc { return func() string { return "World"Followed by paragraphs of text and never any of the rest of the code. For the trivial example above, that's fine, but it's harmful to clarity when it's not trivial. While you can clone the Github repo (which relies on Glide and old, pre-Go Mod setup tools), it's very annoying to not see the full, compiling code together in the book. I don't know how the trade off between that and including non-informative memes and images was made. There are also some images that are the reference code for a section, and generally the print copy has poor image quality, so you're also a bit hamstrung in those situations.The same goes for instances where the images were originally in color, and the text references the color differences in the images which are printed in fuzzy grayscale. Sometimes the images being referenced are of a terminal and related just to setting up a program using Glide, or they may show log output, and they're again, less than clear and filled with noise from third-party tooling that (as of 2020) you may well not be using in a professional environment.You may well love the style and have a great time reading a 600 page book that could have likely been a fraction the size if the useless memes and images were cut out or reduced, and the chapters edited down to be more focused and specific to Go, a language feature, or underlying concept at hand. At the end of the day you'll learn something from this book about FP if you stick through it. I don't want to make little of how much raw knowledge Sheehan has about the topic. There's a lot here. It's just poorly structured and a slog to try and get through.If the book gets edited properly and re-released it'd probably turn into a gem. I'm sure you can sense my disappointment that that didn't happen in this go. The current state of affairs may be more the fault of the Packt editing team, so I don't mean to point fingers at the author himself unfairly. If you read this, Mr. Sheehan, please keep writing, but find a good editor!

I am not that far in, but I like the book. Let's get that out of the way.My issues are with the kindle delivery mechanism. So this means that any negativity about the product *delivery* falls on the shoulders of the author. The publisher is like the absentee landlord. So I bump the stars for the author, but good luck with buying it from Kindle.It seems to be formatted differently (scrolls and not page flip) which makes me think this is the reason I can't read it like other IT books I have bought in this manner.I like the "paper edition 'limitations'" better: - Physical possession is the single requirement for access. - No other special 'limitations'.

I don't know what book other reviews talking about amazing quality got. The git repo is the wrong link, the first cars.go program is named different from the src. I'm at page 23 and the code in text example misses a fundamental required syntax (as in its written wrong in the book) that you can find in the code.

I don't have a background in functional program, so this is an important book for me.If you don't know Go, learn Go from "The Go Programming Language" by Alan A. A. Donovan and Brian W. Kernighan. This is the Golang equivalent of the K&R C book.Then, read this book ("Learning Functional Programming in Go" by Lex Sheehan), Especially valuable for programmers who don't know functional programming. I learned a ton just working through the first example (memoizing a fibonacci function). It helped cement my understanding of first class functions.Thank you Lex for taking the time and effort to write the book. Brilliant job.

A little bit of Go, a little bit of Haskell, a little bit of everything else and a lot of confusion. Did you know that "writing good code is not unlike a good game of soccer?". Did you know that "A lambda calculus is like chocolate milk?". "A link from favorite's to Reddit and from Reddit to an image doesn't mean that there is a link from favorite's to the image. which means that [something] doesn't compose." Did you know that "What happens in the functor box is not unlike what happens when a person entertains impure thoughts?" Those are meant as jokes - I guess - and if you're ok with so freestyle writing you will ♡ this book. Note 1: ♡ is the group operator, used to explain homomorphic encryption in 12 lines and one image. Note 2: there's a typo there, right? It should be ea+b=ea*eb.Chapter 10 is great! Overall it's a good 250-page book, interleaved with an irrelevant 380-page book of divergent thinking with historical references, jokes, surveys of other programming languages and various techniques e.g. SOLID and DDD. With some more strict editing from Packt, 3 extra months, and 380-pages less, this would be a great book.