This is actually my first Haskell project. I feel pretty comfortable with monads, and I haven't read the Baroque Cycle yet. :-)

Not the op nor on their team but I do work at a company using Haskell for grpc services, internal cli tools, cloud web services, and heavy duty (and high performance) parallel parsing.

I'm a polyglot programmer and appreciate the features of many different languages but I couldn't imagine foregoing the benefits of Haskell's type system, reasoning about code algebraically, and leveraging the rock solid GHC RTS for some of the mission critical things we're doing. Rust would probably be my only other consideration for performance reasons but its ecosystem is more immature than Haskell's and some things are very clunky to express in rust (even with its enlightened type system) that are very clear in Haskell.

Haskell may not be the right choice for every team or project but it certainly has been for me for many years now on many (though not all) projects.

Clojure doesn't have a strong adoption within Facebook.

You can read more on Reddit: https://www.reddit.com/r/haskell/comments/68obk4/open_sourci...

Yes.

Build times for this library haven't cropped up as a first-order concern. Using GHCI and `stack test` for the dev workflow has been fast enough (though could always be better).

I'm assuming you're asking what's important in writing "production" Haskell rather than "toy example" Haskell.

Ixiaus's point about mechanics more than theory certainly rings true, though we did think a lot about whether to use GADTs for the Dimension type. Overall I see this as similar to writing "production" code in other languages, going through a couple feedback loops using real use-cases. Profiling to find the bottlenecks, observing how APIs are used in practice compared to intent, and reaching the service to a stable equilibrium.

Not the op nor on their project but I do work at a company using Haskell to solve interesting theoretical problems and for mundane software like cli tools and grpc services and web services.

Most people have an assumption that production Haskell involves a lot of theory when that's actually more the exception I think. My day to day use of Haskell (with the exception of a few projects) is as a strongly typed imperative language. In order to use it in production in that capacity you should have an intermediate level understanding of the type system so that you can wire library apis up and use them.

The productivity gains from Haskell's type system are quite large and they compound, particularly when you have multiple people massaging the​ code base.