Recs.
Updated
SpecsUpdate
Pros
Pro Trustworthy code
Referential transparency and algebraic types mean that code, whether yours or someone elses', is verified to meet a minimum level of stability and compatibility that can't reasonably be guaranteed in procedural/OOP languages. This means less time searching for libraries and attempting to judge them by their test suite, coding style, and number of contributors, and similarly less of the same when trying to bring new programmers onto your project.
Pro Safe Concurrency/Composable Transactions
Software Transactional Memory makes getting concurrency right tractable
Pro Correctness over Backwards Compatibility
The community has often opted to address issues such as Applicative not being a superclass of Monad, rather than maintaining backwards compatibility. This minimizes the need for developers to memorize or wrap APIs that are inconsistent for historical reasons, which are common issues for once-popular ecosystems and those that prioritize interoperability, and reduces biolerplate and edge cases in the long-term.
Pro Mathematical consistency
As Haskell lends itself exceedingly well to abstraction, and borrows heavily from the culture of pure mathematics, it means that a lot more code conforms to very high-level abstractions. You can expect code from vastly different libraries to follow the same rules, and to be incredibly self-consistent. It's not uncommon to find that a parser library works the same way as a string library, which works the same way as a window manager library. This often means that getting familiar and productive with new libraries is often much easier than in other languages.
Pro Lazy Evaluation
Non-strict evaluation leads to modularity and allows recursion over infinite data structures without any syntactic overhead.
Also it allows to use certain constructs only available in impure, mutable state, languages, without sacrificing referential transparency or purity.
Pro Easy to read
Haskell is a very terse language, particularly due to its type inference. This means there's nothing to distract from the intent of the code, making it very readable. This is in sharp contrast to languages like Java, where skimming code requires learning which details can be ignored. Haskell's terseness also lends itself to very clear inline examples in textbooks, and makes it a pleasure to read through code even on a cellphone screen.
Pro Also used as a research language
Haskell is often one of the first languages to get access to bleeding-edge tools, whether new language features or domain-specific tools like libraries for FRP, NLP, or CRDTs.
Pro Referentially transparent
Haskell's Purely Functional approach means that code is referentially transparent. This means that to read a function, one only needs to know its arguments. Code works the same way that expressions work in Algebra class. There's no need to read the whole source code to determine if there's some subtle reference to some mutable state, and no worries about someone writing a "getter" that also mutates the object it's called on. Functions are all directly testable in the REPL, and there's no need to remember to call methods in a certain order to properly initialize an object. No breakage of encapsulation, and no leaky abstractions.
Pro Highly transferable concepts
Haskell's referential transparency, consistency, mathematics-oriented culture, and heavy amount of abstraction encourage problem solving at a very high level. The fact that this is all built upon little other than function application means that not only is the thought process, but even concrete solutions are very transferable to any other language. In fact, in Haskell, it's quite common for a solution to simply be written as an interpreter that can then generate code in some other language. Many other languages employ language-specific features, or work around a lack of features with heavy-handed design patterns that discourage abstraction, meaning that a lot of what is learned, and a lot of code that is needed to solve a particular problem just isn't very applicable to any other language's ecosystem.
Pro Popular in teaching
Haskell is really popular in universities and academia as a tool to teach programming. A lot of books for people who don't know programming are written around Haskell. This means that there are a lot of resources for beginners in programming with which to learn Haskell and functional programming concepts.
Cons
Con Difficult learning curve
Haskell lends itself well to powerful abstractions - the result is that even basic, commonly used libraries, while easy to use, are implemened using a vocabularly that requires a lot of backround in abstract mathematics to understand. Even a concept as simple as "combine A and B" is often, both in code and in tutorials, described in terms of confusing and discouraging terms like "monad", "magma", "monoid", "groupoid", and "ring". This also occasionally bears its ugly head in the form of complicated error messages from type inference.
Con Learning requires a higher initial investment than other languages
For programmers used to Procedural languages, Haskell is a switch from what they're used to. Couple this with jargon borrowed from abstract algebra and code described at a very high level of abstraction - there's no denying it's a bit intimidating.
Con Intended as an example language to guide research. Not intended for real-world productivity
It's perfectly fine to learn it to expand your knowledge. But since the question asks real "server-side programming language", dynamic functional languages designed for production such as Elixir are much better.
Con Language extensions lead to unfamiliar code
Haskell's language extensions, while making the language incredibly flexible for experienced users, makes a lot of code incredibly unfamiliar for beginners. Some pragmas, like NoMonomorphismRestriction, have effects that seem completely transparent in code, leading beginners to wonder why it's there. Others, like ViewPatterns, and particularly TemplateHaskell, create completely new syntax rules that render code incomprehensible to beginners expecting vanilla function application.
Con Symbols everywhere
Haskell allows users to define their own infix operators, even with their own precedence. The result is that some code is filled with foreign looking operators that are assumed to be special-case syntax. Even for programmers who know they're just functions, operators that change infix precedence can potentially break expectations of how an expression is evaluated, if not used with care.
Con Correctness over Stability
The community has, particularly as of late, opted to correct issues with the language and its core libraries, rather than maintain backwards compatibility. This could create issues for using Haskell in production, where it may not be practical to prioritize issues caused by these changes when they happen.
Con Still some rough edges in the ecosystem
While the community is actively working on implementing changes, there are still a handful of nagging issues with the ecosystem. Error/Exception types are still not fully standardized, and Records are still a work-in-progress. Many libraries also still have yet to catch up with newer conventions the community has settled on. This will likely continue to be the case for a while, as the language itself is still moving quickly, with talk of possibly picking up features like linear or dependent types in the near future.
Con Lazily evaluated
Haskell's lazy evaluation implies a level of indirection - you're not passing a value, you're passing a thunk. This is often difficult to grasp not just for beginners, but for experienced programmers coming from strictly evaluated languages. This also means that, since for many, strict evaluation is their first instinct, initial expectations of a function's performance and complexity are often broken.