Are there any downsides or problems with Haskell?

Question

I'm looking at diving into Haskell for my next (relatively trivial) personal project. The reasons that I'm tackling Haskell are:

1. Get my head into a purely functional language
2. Speed. While I'm sure this can be argued, profiling that I've seen nails Haskell close to C++ (and seems to be quite a bit faster than Erlang).
3. Speed. The Warp web server seems to be crazy fast in comparison to virtually everything else.

So, given this, what I'm looking for are the downsides or problems that come along with Haskell. The web has a tremendous amount of information about why Haskell is a Good Thing, but I haven't found many topics about its ugly side (apart from gripes about its syntax which I don't care about at all).

An example of what I'm looking for could be like Python's GIL. Something that didn't rear its head until I really started looking at using concurrency in a CPython environment.

Answer 1

A few downsides I can think of:

• Due to the language's nature and its firm roots in the academic world, the community is very math-minded; if you're a pragmatic person, this can be overwhelming at times, and if you don't speak the jargon, you'll have a harder time than with many other languages.
• While there is an incredible wealth of libraries, documentation is often terse.
• Gentle entry-level tutorials are few and hard to find, so the initial learning curve is pretty steep.
• A few language features are unnecessarily clumsy; a prominent example is how record syntax does not introduce a naming scope, so there is no way to have the same record field name in two different types within the same module namespace.
• Haskell defaults to lazy evaluation, and while this is often a great thing, it can bite you in nasty ways sometimes. Using lazy evaluation naively in non-trivial situations can lead to unnecessary performance bottlenecks, and understanding what's going on under the hood isn't exactly straightforward.
• Lazy evaluation (especially combined with purity and an aggressively optimizing compiler) also means you can't easily reason about execution order; in fact, you don't even know whether a certain piece of code actually gets evaluated in a given situation. Consequently, debugging Haskell code requires a different mindset, if only because stepping through your code is less useful and less meaningful.
• Because of Haskell's purity, you can't use side effects to do things like I/O; you have to use a monad and 'abuse' lazy evaluation to achieve interactivity, and you have to drag the monadic context around anywhere you might want to do I/O. (This is actually a good feature in many ways, but it makes pragmatic coding impossible at times.)

Answer 2

Most of Haskell's downsides (as well as most of Haskell's upside) come from its two defining characteristics: It's lazy and purely functional.

Being lazy makes it harder to reason about performance. Especially for people not used to laziness, but even for experienced Haskellers it can be hard to see how laziness will affect performance in certain cases.

Laziness also means that it's harder to create accurate benchmarks without using libraries like Criterion.

Being purely functional means that whenever you need to use mutable data structures (in cases where it's not possible to achieve the desired performance without them - though thanks to GHC's optimizer that doesn't happen as often as you might think), you'll be stuck in the IO (or ST) monad, which makes the code more cumbersome.

Since you mentioned speed as one of your goals, I should point out that there are often huge differences in performance between hand-optimized Haskell code and Haskell code that was written without giving much thought to performance (more so than in other languages). And hand-optimized Haskell code is often quite ugly (though I suppose that is also true in most other languages).

Answer 3

I am not a Haskell expert: I have learnt the basics but unfortunately I haven't had the chance to do some serious project in Haskell (I would like though, because I like this language a lot).

However, from what I know and from a discussion with somebody who's been working in a field quite close to functional programming, Haskell might not be the best solution when you want to implement graphs algorithms, where you need e.g. to walk through the graph and perform many local changes on the graph structure.

Since a graph does not have a recursive structure in general, my feeling is that the best approach is to build one copy of the graph using structures and pointers between them (as you can do e.g. in C++) and manipulate that copy by changing pointers, creating or destroying nodes, and so on.

I wonder how such data structures and operations can be handled properly in Haskell, since to my knowledge in Haskell it is not possible to use the above representation / approach. Some problems with graph algorithms in Haskell are briefly discussed in this article

EDIT

I recently spoke with an expert of functional programming and he confirmed that implementing certain graph algorithm efficiently can be quite tricky in Haskell: moving around pointers like you do in C or C++ can be much faster.

Answer 4

The down side to Haskell is that its different. It's a bigger step away from languages that are more commonly taught or talked about, so there will be a larger learning curve. It's also less popular of a language which may limit availability of help if you get stuck. These really aren't major downsides though.

The one thing that is a potential downside is that it's a functional language, so it is less useful for certain problem domains, but this is true for object oriented languages as well. Generally languages don't have true negatives beyond learning curves, at least for the relatively popular languages. As long as a language is Turing complete it is theoretically capable of anything.

Answer 5

So, given this, what I'm looking for are the downsides or problems that come along with Haskell

The "problems with Haskell" tend to appear in certain domains. Haskell is a wonderful language for applications programming, far more pleasant to write than just about anything else. The problems tend to crop up when you try to do something there isn't good support for, such as:

• Cross compiling. GHC can be built as a cross compiler, but the process is rather involved.
• Embedded applications. Haskell has memory management via a garbage collector, so this one isn't too surprising.
• Speed. Haskell is not as fast as Rust, though in most cases it will compete fairly well. It depends heavily on the application domain - pure computations get optimized well, but something like "read a file into a buffer and count the number of lines" is harder to express in Haskell.