The Strengths Of Haskell (42 strengths listed so far)

[human154]

With your help, I would like to make a list that explores the strengths of Haskell.

Please add, comment or elaborate on these strengths and give examples, stories etc.

To discuss, or elaborate on a point, please select it along with the hashtag and click the “quote” popup to include the quote in your post. This will make it easier to search for posts on a certain topic.

If you suggest new points I’ll edit this post to expand the list (or I’ll try to fix my mistakes if you suggest corrections ).

#strength000 - The Compiler is “Industrial Grade” (Haskell is reliable enough that you can trust it with the production code that your business depends on)

#strength001 - Static Typing i.e. Compile Time Checking Of Code (This forces some work to be done before code is run and it forces some loss of [dynamic typing] flexibility, but it helps software not to crash for a user!)

#strength002 - Developer Productivity (Once a team gels and knows Haskell well enough they can have very high productivity)

#strength003 - Garbage Collected (Haskell avoids the complexity and dangers of managing memory manually. This contributes to making Haskell more productive (as in the previous point) as a “high level language” where you can focus more on your main task than the low level workings of a computer)

#strength004 - Function Type Signatures (Signatures are sometimes described as documentation that gets checked by the compiler i.e. you can rely on the type signature to be accurate. This has also been called a nice lightweight proof embedded in your code.)

#strength005 - Good Runtime Speed (Haskell may sometimes be about 3 times slower at runtime than C but its also faster than Swift, F#, JavaScript, Erlang and many others)

#strength006 - Advanced Type System (Increases safety and flexibility. You can rest assured that right now there teams working on integrating new, valuable, advanced type level features.)

#strength007 - A Community Of Individuals Large Enough to Support a Healthy Ecosystem Of Libraries And Tools

#strength008 -(edited to add “Identifiably”) Identifiably Pure Functions (You can count on reliably getting the same results out of a pure function. This enhances programmers’ ability to reason about Haskell code.)

#strength009 - Great Concurrency https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/lang-parallel.html

#strength010 - Great Support for Parallelism (see link above)

#strength011 - Lazy Evaluation (Avoids unnecessary evaluation of code, allows for infinite data structures and custom control flow structures. (I think this somehow relates to ease of refactoring?)

#strength012 - Elegant Syntax With Less Noise Than Most Languages

#strength013 - Increasingly Awesome Good Language Server Support (a few years ago there wasn’t much language server support and now it can do some pretty cool things)

#strength014 - Great For Domain Modelling With Algebraic Data Types

#strength015 - Good Support for Generating Documentation

#strength016 - Immutable Values Everywhere (This often makes functions simpler to understand than Python (for example) since in Haskell you don’t need to determine if a function does or does not mutate a value passed to it)

#strength017 - Type Inference (You don’t need to always write out types) [Thank You @jaror]

#strength018 - Good Support for eDSLs, such as Parser Combinators (partly due to good support for custom operators). [Quoted from @jaror, Thank You!]

#strength019 - Coherent Type Classes (which allow you to write safe, polymorphic, and efficient data structures, such as sets based on binary search trees. Almost all languages can only achieve two of those three points.) [Also quoted from @jaror, Thank You Again]

#strength020 - Functional Style Programming (shamelessly stolen from @gilmi’s Consider Haskell)

#strength021 - Maintainable Code - Refactor With Confidence (This is largely a consequence of static typing (point 001) but arguably it is about a confluence of features [see State Of The Haskell Ecosystem # Maintenance Thank you for the link @gilmi! ]

#strength022 - Great Support For Automatic Testing ( see the Quickcheck Library)

#strength023 - Type Driven Development State Of The Haskell Ecosystem # Type Driven Development [Thank You @gilmi]

#strength024 - Compiler Extensibility (GHC successfully enables all kinds of features to be tried and used before a commitment needs to be made to extend the language )

#strength025 - Haskell Has A High Level Of Internal Consistency With A Sharp Focus On The Pure, Functional Paradigm (With its roots in academia and the lambda calculous and a perhaps obsessive, uncompromising pursuit of “purity”, Haskell is highly opinionated and feels like it has a very solid foundation. In other words it feels like its not a somewhat random, hacked together, kitchen sink language.)

#strength026 - Developers Express A Sense Of “Peace of Mind” When Putting Code Into Production. (a result of a combination of the above features)

#strength027 - The New Haskell Foundation (A central organization with a mission to nurture the Haskell ecosystem and its already succeeding at securing significant financial resources from corporate and individual donors.)

#strength028 - There Are A Slew Of Businesses Willing To Support The Ecosystem (They are making increasingly significant financial contributions to the Haskell Foundation and also paying some employees to work on Haskell infrastructure)

#strength029 - The Haskell Community Has A Bunch of Teams, Organizations And Committees Devoted To Helping Haskell Succeed In Various Specialized Ways.

#strength030 - Haskell Is Not Controlled Or Tied To A Single Large Corporate Sponsor (Hopefully this leads to a greater sense of community ownership.)

#strength031 - Haskell Is Multiplatform (Windows, Linux and Mac operating systems all work effectively with Haskell)

#strength032 - Haskell Has A REPL

#strength033 - Haskell Has A Team Focused On Increasing The Quality Of Base Library Documentation (https://gitlab.haskell.org/ghc/ghc/-/issues/17929)

#strength034 - Functional Architecture (functional architecture blog post, functional architecture podcast Book: Functional Design And Architecture

#strength035 - Dedicated/Uniform Ecosystem(With languages like Kotlin, Scala, Elixir, Clojure etc. “benefiting” from the wider ecosystem also means being prepared to work in a second language/paradigm.)

#strength036 - "Equational Reasoning"

#strength037 - A Focus On Composition Over Inheritance (Type Classes)

#strength038 - Pattern Matching

#strength039 - List Comprehensions (thanks @ddavo)

#stength040 - There Are More Than 30 Books Available On Haskell

#strength041 - There Are A Bunch Of Free Resources For Learning Haskell
Collection Of Links To Resources For Learning Haskell

#strength042 - Hoogle (Search for functions by type signature)

[jaror]

I would add good support for eDSLs such as parser combinators (partly due to good support for custom operators).

One other advantage of laziness is that IIRC it has been proven that immutable strict code is sometimes necessarily a factor log n slower than mutable code, while this result has not been proven for lazy code and indeed it is often possible to write lazy code that achieves better asymptotics than strict code. Laziness also makes it possible to build cyclic structures without mutation.

And I think 1, 4 and 6 sound similar.

Oh, and how could I forget: coherent type classes, which allow you to write safe, polymorphic, and efficient data structures, such as sets based on binary search trees (almost all languages can only achieve two of those three points).

[gilmi]

See:

• State of the Haskell Ecosystem
• Consider Haskell (self plug)
• Promote Haskell

[jaror]

haskell.org also lists six points, one new point is type inference:

You don’t have to explicitly write out every type in a Haskell program. Types will be inferred by unifying every type bidirectionally. However, you can write out types if you choose, or ask the compiler to write them for you for handy documentation.

Although, “unifying every type bidirectionally” is way too much jargon to use in promotional material in my opinion.

[jneira]

That is a great summary of haskel pros’s.
However i always miss in those kind of posts the weaknesses. Some of them are just the other side of some pros’s and they are still missed more. Things you have to paid to have them

[hasufell]

I’ll challenge some of these points, because agreeing doesn’t help us hash out arguments

---

@human154

#strength002 - Developer Productivity

IME, there are languages with higher productivity. I’ll call TypeScript as one of those. It does scale maybe a little different: in the beginning, definitely higher productivity. For long-term projects it still scales well, but maybe after a couple of years, Haskell starts to take over.

As such, Haskell’s strength really is long/high maintenance projects. One-off microservices doesn’t seem like a good use case for Haskell, for example.

@human154

#strength003 - Garbage Collected

You can have memory safety without GC. And some applications are made harder due to long-pause GCs. Also see https://well-typed.com/blog/2019/10/nonmoving-gc-merge/

@human154

#strength005 - Good Runtime Speed

Getting proficient with Haskell performance optimization is a dark art that many Haskellers never learn, because it requires quite deep knowledge about GHC internals. I’d say this is one of the more controversial parts about Haskell.

@human154

#strength006 - Advanced Type System

Yes, but I’d argue that type-level programming is rather unwieldy and there are languages that do this more elegantly. DataKinds, TypeFamilies etc can be confusing and often produce hard to follow code.

@human154

#strength008 - Pure Functions

It’s not so much “pure functions”, because every language has them. It’s that the language is pure, which is often misunderstood: readFile :: FilePath -> IO String is pure. And is the language being pure really something the developer cares about or more of a nice property for compiler engineers? Because although readFile is pure, I have to reason about it operationally, I can’t reason about it denotationally. That’s all that matters for the programmer, imo, not purity.

@human154

#strength010 - Great Support for Parallelism

Does it? Exception handling, async library, IORefs etc all aren’t particularly trivial and there’s no first-class support for parallelism like in Go. Maybe that’s for the better, I’m not sure.

@human154

#strength011 - Lazy Evaluation

Is a great source of space leaks: https://www.reddit.com/r/haskell/comments/pvosen/how_can_haskell_programmers_tolerate_space_leaks/?utm_source=share&utm_medium=web2x&context=3

@human154

#strength013 - Increasingly Awesome Language Server Support

It’s getting better, but in terms of tooling we’re still far behind than most languages.

@human154

#strength017 - Type Inference

Often doesn’t play well with type-level programming, e.g. open sum types.

@human154

#strength024 - Compiler Extensibility

In fact, it is so extensible that we haven’t managed to create a new language report. Good or bad?

@human154

#strength026 - Developers Express A Sense Of “Peace of Mind” When Putting Code Into Production

This one I can’t agree on. I’ve had terrible bugs in Haskell code that brought down an entire backend or made legal signing of documents impossible due to an amazonka bug.

@human154

#strength028 - There Are A Slew Of Businesses Willing To Support The Ecosystem

I think there are only a couple and most haskell companies produce proprietary code and rarely publish any library, let alone allow their employees to work on libraries during their work time.

@human154

#strength030 - Haskell Is Not Controlled Or Tied To A Single Large Corporate Sponsor

I hope it stays that way.

@human154

#strength031 - Haskell Is Multiplatform

Windows often works not so well. Many GHC versions on windows are defunct. cabal and other tools suffer from MAX_PATH issues. Handling of msys2 is hard and confusing. Library support is sometimes sub-par.

[human154]

The Strengths Of Haskell (31 strengths so far)

That is a great summary of haskel pros’s. However i always miss in those kind of posts the weaknesses. Some of them are just the other side of some pros’s and they are still missed more. Things you have to paid to have them

I find the tradeoffs very interesting too!

In order to get productivity and safety, Haskell has (in part) the disadvantages that come with a garbage collector (its often several times slower than C, could have GC pauses etc.)

If Haskell’s advanced features are used, there is a risk of creating a learning overhead/requirement for others who haven’t understood those features. (some languages avoid advanced features for that reason.) This could mean extra time spent training employees to learn advanced features, or that it could be harder for administrators to reassign a Haskell employee who can maintain advanced code because its harder for someone else to take over. (On the other hand, some would point out that the complexity is inherent to the problem, so the actual complexity is there either way it just takes different forms)

Haskell has strong internal consistency in being “purely functional”. This sharp focus on the pure functional programming paradigm makes Haskell different. Different is often interesting but it means there is more to learn up front with Haskell for most developers with experience in other languages. So Haskell has traded off some ease of learning just by being different.

Lazy evaluation, provides the benefits listed but when it is necessary to think about how the code will actually execute at runtime, laziness can make the reasoning more difficult. (Note you can use the “!” symbol to make code strictly evaluated, but it requires experience to know when to use it).

The trade offs that Haskell makes, make it good for writing applications more than "systems programming " like C and Rust, where developer productivity is sacrificed for the sake of a primary focus on enabling the absolute fastest execution of code possible

Haskell’s static typing and general inclination towards safety mean its generally less malleable and flexible than dynamically typed languages like Clojure, Javascript, and Python for example. Arguably, I think it might also be more fun to just get in a car and go rather than waiting for someone to do a circle check then having them force you to fix the break light before leaving…In terms of programming, it can be a more fun to use a dynamic language that doesn’t force you to fix the problems that the Haskell compiler will insist that you fix. On the other hand, even if it isn’t as much fun to code Haskell in that sense, the compiler is quite helpful if you do need these problems to be fixed.

[jaror]

@human154

In terms of programming, it can be a more fun to use a dynamic language that doesn’t force you to fix the problems that the Haskell compiler will insist that you fix.

-fdefer-type-errors has been implemented for that use-case, but maybe the ecosystem of dynamic languages is even more forgiving.

[gilmi]

I’ll challenge some of the challenges then

---

@hasufell

there are languages with higher productivity

Sure, but I think Haskell ranks pretty high in terms of productivity, at least for me.

@hasufell

You can have memory safety without GC

I agree that this is a trade-off, GC is cited to provide better productivity (from not having to think about memory management as much), but it also restricts the kind of applications that can be built using a GC (though still many applications, including games, can be built in GCed langauges).

@hasufell

Getting proficient with Haskell performance optimization is a dark art that many Haskellers never learn

I feel like idiomatic Haskell can provide good performance compared to many languages when the right algorithms/data structures are used. Though getting Haskell to go ‘real-fast’ is more of a dark art as you said.

@hasufell

I’d argue that type-level programming is rather unwieldy and there are languages that do this more elegantly. DataKinds, TypeFamilies etc can be confusing and often produce hard to follow code.

I think we should also make the distinction between type level programming such as data kinds and type families and the less cutting-edge but still advanced type features compared to more common languages, such as ADTs, higher-kinded types and type classes which are much less unwieldy and confusing and are still very powerful and useful.

@hasufell

And is the language being pure really something the developer cares about or more of a nice property for compiler engineers?

Maybe it’s not purity, but rather referential transparency and local reasoning which are very useful for developers - being able to apply equational reasoning is very powerful because it allows us to look at code in isolation without considering the context, rearrange code and refactor safely without changing the meaning of it.

@hasufell

Exception handling, async library, IORefs etc all aren’t particularly trivial and there’s no first-class support for parallelism like in Go. Maybe that’s for the better, I’m not sure.

Could you expand on that? I’m not really familiar with many other concurrent/parallel API, but I was under the impression that Eval, Async and STM are pretty awesome.

@hasufell

[Lazy Evaluation] Is a great source of space leaks

It is also very convenient and has better compositionality than strict evaluation. For example Haskellers can define their own control flows such as bool, maybe, unless, when, etc. And writing recursive parsers in Haskell is much more pleasant than in, say, Elm.

@hasufell

[Type inference] often doesn’t play well with type-level programming, e.g. open sum types.

Didn’t we say type-level programming is rather unwieldy and confusing? Whether a feature has good type inference or not is often a good indication on whether it has good power-to-weight ratio / is it worth using it or not (imo).
Having type inference is great for prototyping, exploratory programming, and refactoring, as we don’t have to repeatedly tell the compiler additional information.
Also, do you mean polymorphic variants when you say open sums? With a few restrictions to the feature, we could have type inference on polymorphic variants.

@hasufell

[Compiler Extensibility] In fact, it is so extensible that we haven’t managed to create a new language report. Good or bad?

Is it really true that we haven’t seen a new standard because GHC is extensible?

@hasufell

Windows often works not so well. Many GHC versions on windows are defunct. cabal and other tools suffer from MAX_PATH issues. Handling of msys2 is hard and confusing. Library support is sometimes sub-par.

Not to invalidate your experience, but I’ve also had positive experiences working with Haskell in windows, for example, I developed a game using SDL2 on Linux, and was able to compile and run it on OS X and Windows fairly easily using Stack (instruction in the readme). I’ve also had previously a not very good experience trying to run a java program on linux (developed on windows). So YMMV.

---

One thing I would add that isn’t great atm (imo) is that there isn’t really established practices on how to deploy Haskell programs to users. I used ghc-musl as well as hsinstall to build static binaries/package applications, but this is definitely not trivial. Would love to see this topic made easier or at least explained somewhere.

[hasufell]

One thing I would add that isn’t great atm (imo) is that there isn’t really established practices on how to deploy Haskell programs to users. I used ghc-musl as well as hsinstall to build static binaries/package applications, but this is definitely not trivial. Would love to see this topic made easier or at least explained somewhere.

You don’t need any of that, you just need a stock alpine docker image and start building! ghcup supports alpine just fine, see https://github.com/hasufell/stack2cabal/blob/afa113beb77569ff21f03fade6ce39edc109598d/.github/workflows/release.yaml#L35 for an example

[gilmi]

That’s great to know! Would love to see a blog post (or even a discourse post) about the small details if you have time.

[human154]

@hasufell
Regarding:
#strength028 - There Are A Slew Of Businesses Willing To Support The Ecosystem

you said:

@hasufell

I think there are only a couple and most haskell companies produce proprietary code and rarely publish any library, let alone allow their employees to work on libraries during their work time.

The Haskell Foundation has received more than $450 000 in donations from more than 12 corporations in its first year, with more to come.

A somewhat outdated (but nice and concise) update on the financials is here:

Live Update List of Haskell Foundation Funding

Hi everyone, thank you for this feedback! I absolutely agree that more transparency in our financials is a great idea, and in that spirit I’m going to summarize where we’re at right now, and how we’re thinking about next year’s budget. 2021 Emily and I started full time on Feb 22nd, 2021. At that point the wonderful people who got the Foundation up and running had raised $327,0000. That fundraising success gave the Interim Board confidence that bringing on two people full time was financially r…

In that post Andrew lists the following sponsors:
IOHK - $125,000
GitHub - $70,000 *Note: This contribution is earmarked for GHC developer support
Well Typed - $25,000
Mercury - $12,000
Flipstone - $20,000
Tweag - $25,000
Obsidian - $25,000
EMQ - $25,000
Digtal Asset - $70,000
Exfreight - $25,000
TripShot - $10,000
HERP - $10,000

My understanding is that Serokell is paying 3 people to implement dependent types in GHC.

I’m going to start a new thread to see if people will list these types of contributions that companies are making:

How Does Your Business Contribute Back To Haskell?

I know about these financial contributions to the Haskell Foundation… IOHK - $125,000 GitHub - $70,000 *Note: This contribution is earmarked for GHC developer support Well Typed - $25,000 Mercury - $12,000 Flipstone - $20,000 Tweag - $25,000 Obsidian - $25,000 EMQ - $25,000 Digtal Asset - $70,000 Exfreight - $25,000 TripShot - $10,000 HERP - $10,000 I believe Serokell is paying 3 people to work on dependent types for Haskell. https://serokell.io/blog/developing-ghc-for-a-living …T…

[ddavo]

Speaking of a list of strengths, what about list comprehensions and other syntactic sugar things?

Also, the way of overloading operators and functions is really nice!

[hasufell]

@human154

The Haskell Foundation has received more than $450 000 in donations from more than 12 corporations in its first year, with more to come.

Yeah, well-typed is an awesome Haskell wizardry company. IOHK produces massive amounts of high-quality Haskell open-source code. I only know a little about the others, but yeah, those are really only a couple.

Companies on that list either attract academics or have extremely strong funding (e.g. fintech).

[graninas]

#strength034 - Functional Architecture (functional architecture blog post, functional architecture podcast 1

Nothing about my book?

[human154]

@graninas
Sorry for the oversight. I’ve added a link in the list. Book: Functional Design And Architecture

[human154]

@hasufell

In response to: #strength013 - Increasingly Awesome Language Server Support

you wrote:

@hasufell

It’s getting better, but in terms of tooling we’re still far behind than most languages.

Haskell is one of the 50 most popular programming languages, and there are thousands of languages, probably hundreds were created in the last year. So most languages would actually have much worse tooling.

It would be more accurate to say that Haskell has not yet reached the level of tooling of some of the absolutely most popular and heavily invested in languages.

On the other hand, Python, JavaScript, Ruby etc… are more popular but arguably Haskell still has better tooling if you count Haskell’s compiler as a tool.

[graninas]

@human154 Oh, this is so kind, thank you!

[human154]

@graninas

Thank you for taking the time to write and publish the book!

[ntwilson]

@human154

Haskell is one of the 50 most popular programming languages, and there are thousands of languages, probably hundreds were created in the last year. So most languages would actually have much worse tooling.

Maybe it would be more fair to say “in terms of tooling, the Haskell developer experience is still far behind most developers’ typical experience.” In other words, if you list tooling as a strength of Haskell with the intent of “selling” Haskell to other developers who are currently using the most popular languages, most developers are going to be disappointed, because their tooling experience will actually be worse than what they’re used to. If the intent is rather to rank up Haskell against all other programming languages in existence - even the obscure ones - then yeah, the tooling is pretty great, but I don’t think that’s as useful of an approach.