Dynamically typed functional languages like Clojure and Elixir are now at the point where I'd feel comfortable basing a commercial application on them. If you use Clojure instead of Java, or Elixir and Phoenix instead of Ruby on Rails, you'll be fine. Your app might still fail, but that won't be because of the technology stack.

Some statically typed languages mix functional programming and object-oriented programming. Some of them, like F# and Scala, are also safe choices.

This book was conceived as an attempt to demonstrate that the purer statically typed languages – ones like Elm, Haskell, and PureScript – are suitable for adoption by the early mainstream. That would require that they be well suited to handling messy domains, have the surrounding infrastructure necessary for language success in the modern day, and that the "how" of using the language features is well understood and accessible to a mainstream audience.

If so, the book would be poised to catch a wave.

"Brian @marick is always five years ahead of everything so I'll be buying this." – Michael Feathers, author of Working Effectively with Legacy Code, tweet of 23 May 2017.

Alas, I've concluded that five years is an underestimate. The languages have progressed, but not fast enough. That is, their advantages over mixed or dynamic languages are small enough that accepting their extra hassle and risk isn't a bet I'd care to make.

To be clear: these languages are solid, as languages. However, they require more dedication and work than more established languages, and I don't think they yet pay that back. It's not that they don't have benefits – it's that the cost is too high.

That leaves two possible uses for the book.

First, the language I'm most likely to be wrong about is Elm, a language for the browser front end. This book covers it in considerable depth.

"I just love the casual style this book is written in, that also happens to be a fantastic guide to Elm!" – Igal Tabachnik, tweet of 23 June 2017.

"I'm really enjoying your book. I've written a couple thousand lines of Elm prior to reading it and this book is filling in the idioms that I was missing. Thanks for writing it!" – Jason Stiebs, tweet of 16 January 2018

One way it may stand out from other Elm books is that I make a concerted effort to explain idioms and useful habits of thought. I try to go beyond "here's how you do this in Elm" to "here's how it fits into the FP programmer's way of approaching problems."

Second, some people find it useful to learn new ideas (like functional style) in the purest form. It makes the ideas stand out more clearly. It can innoculate you against falling back too easily into old habits when using a mixed language, or it can make the "why" behind features in the mixed language stand out more clearly.

If that's your learning style, the Elm section of this book can be for you, because the novelties it explains also appear in the mixed languages.

"Always wanted to learn FP but never found such a good start for an outsider. Awesome!" – Yuri Oliviera, tweet of 8 June 2017.

"I'm really liking your book. Thanks for all the work making it so straightforward to read." – Bill Tucker, tweet of 28 August 2017.

But Elm is a deliberately minimalist language. What about the features it removes from other pure FP languages like Haskell and PureScript? Those features have potential.

"Reading @marick's 'OutsideFp' book. Thoroughly engrossing and a great introduction to #FP using @elmlang. Can't wait for @purescript part." – Lee Owen, tweet of 10 September 2017

I think the features aren't as important as Elm's because they (mostly) don't appear in the mixed languages that you're more likely to use. However, the book does introduce PureScript and tries to explain ideas like type classes and effects differently than the conventional ways, which I generally found unnecessarily difficult to understand.

However, until I stop being "five years ahead of everything" and the pure languages become safer, the PureScript parts of the book are of intellectual, rather than practical, interest.