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
1 Like
I’ll challenge some of these points, because agreeing doesn’t help us hash out arguments 
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.
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/
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.
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.
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.
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.
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
It’s getting better, but in terms of tooling we’re still far behind than most languages.
Often doesn’t play well with type-level programming, e.g. open sum types.
In fact, it is so extensible that we haven’t managed to create a new language report. Good or bad?
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.
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.
I hope it stays that way.
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.
5 Likes
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.
1 Like
-fdefer-type-errors has been implemented for that use-case, but maybe the ecosystem of dynamic languages is even more forgiving.
3 Likes
I’ll challenge some of the challenges then
Sure, but I think Haskell ranks pretty high in terms of productivity, at least for me.
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).
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.
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.
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.
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.
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.
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.
Is it really true that we haven’t seen a new standard because GHC is extensible?
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.
3 Likes
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
1 Like
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.
@hasufell
Regarding:
#strength028 - There Are A Slew Of Businesses Willing To Support The Ecosystem
you said:
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:
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:
2 Likes
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!
2 Likes
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).
#strength034 - Functional Architecture (functional architecture blog post, functional architecture podcast 1
Nothing about my book?
@graninas
Sorry for the oversight. I’ve added a link in the list. Book: Functional Design And Architecture
In response to: #strength013 - Increasingly Awesome Language Server Support
you wrote:
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.
1 Like
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.
2 Likes
My intention with that statement was to refute @hasufell’s statement that Haskell has “worse tooling than most languages”.
Yeah, I think @hasufell’s statement is technically false, but I think the point they were getting at is valid, which is that it doesn’t make sense to list tooling as a strength of Haskell, since it’s behind the “status quo” or the “typical developer experience.”
Of course, with that viewpoint it matters what the intent of the list of strengths is! I suppose I walked in with the assumption that it was sort of Haskell’s strengths relative to that typical developer experience (the sort of list you would use to convince typical developers to use Haskell), and the list could be intending something very different. So perhaps it’s useful to clarify what the list is for?
2 Likes
Clarifying the nature of the list is a good point (I’m thinking about that). I want to be able to list, for example, that there are more than 30 books written about Haskell, which I think is great. I’m sure there are hundreds of books on Java and Python but I don’t think that diminishes the books that Haskell has. So when I said that Haskell has more than 30 books I certainly didn’t (and don’t) mean that “Haskell has more books available than the most popular languages… so therefore use Haskell”, so in general I am making the list from more of an absolute perspective on strengths rather than looking at Haskell relative to how it outdoes the most used languages on these points. I’ll progressively add details to each point to add clarity on this.
I haven’t included a strength about tooling in general, however, as I said in my response to @hasufell, which you quoted, the existence of Haskell’s compiler could mean that Haskell’s tooling is better than that of Python, JavaScript, and Ruby…if you count the compiler as a tool. …and those languages cover a lot of developers.
I actually haven’t seen any listing for the number of developers for each language, and I would be very interested in seeing that. But if most developers are using dynamic languages, for example, then I think there is still a case to be made for “Haskell’s tooling” being superior, even compared to what most developers have experienced.
With what I wrote, I just meant to say that Haskell’s language server support is getting better:
“#strength013 - Increasingly Awesome Language Server Support”
I’m thinking that a few years ago there wasn’t much happening with language server support and now it can do some pretty cool things so that is a positive, and I would like to list it as such.
I refined the point with a clarification, and I changed “awesome” to “good”. So now its:
#strength013 - Increasingly
AwesomeGood Language Server Support (a few years ago there wasn’t much language server support and now it can do some pretty cool things)
Thanks for your thoughts on this!
2 Likes
#strengh172 — Functors in Haskell are strong. 
… I’ll show myself out.
1 Like