What is your least favorite thing about Haskell in 2018?

Recently, “Haskell Weekly News” conducted the “2018 State [sic] of Haskell Survey” and published the data under ODbL v1.0.

This epic survey featured hundreds of largely boring questions about your feels and whatnot… except for two open ended questions which stood out and were able to provide astonishing insights into the minds and hearts of the people of Haskell:

“What is your favorite thing about Haskell?”

“What is your least favorite thing about Haskell?”

In this post, let’s start with the bad news!

100 Things People Hate About Haskell

I’m not going to summarize or cherry pick as this would inevitably distort the data towards representing my personal opinion. Instead I’ll let all the answers to the survey question asking for the least favorite thing(s) about Haskell speak for themselves and let you be the judge.

• Documentation.
• Build times — especially on CI.
• Records are still tedious
• Tooling, ease for newcomers
• Community is unwelcoming and unhelpful. difficult to compare libraries. libraries are often poorly documented, and when programming I often have to spend hours reading the code to understand how to use it. slow compiler times
• Type astronauts
• Complexity is not hidden enough, sometime I miss the ability not to be explicit about some choice, but API are generally extremely verbose and forces you to understand all underneath details of the domain of the library. I would really appreciate if libs started to provide more shortcut functions with most choices already done for me to give me a chance to pick the right choice a bit later.
• I have problems sometimes expressing exact type requirements. Also lack of libraries and difficulty doing things like debugging.
• Flamewars
• We are not good at marketing it to non-Haskellers and non computer scientists. Technical merits alone don’t attract new users. We need to engage more communities who will bring in fresh perspective and domain expertise.
• Lack of best practices and design approaches Low adoption Low count of comprehensive materials Too loud academic haskellers comparing to practical ones
• Exceptions, which undermine confidence that code is correct
• Legacies in the language and Prelude, such as map, return, liftM, etc.
• IDE tooling could be better (talking about neovim)
• Hard to understand type errors, esp. when using some advanced libraries
• Need to enable dozen of lang exts to use almost any advanced lib
• Some standard choice for GUI framework and overall lack of some standard, agreed way to do interactive GUI things like elm architecture. There is nice gi-gtk, but it’s all in IO and callbacks. gi-gtk-declarative looks promising, but there is only one guy doing it. Ideal, imo, would be gi-gtk-declarative + gi-gtk-declarative-simple-app + some frp.
• Having to use both stack and cabal together
• Windows OS story is kinda awful, stack makes it almost manageable but still there are some issues with MSYS and undocumented non-obvious ways to fix’em
• Error messages, tooling, module prefixes, data science (linear algebra, ploting)
• People somehow still manage to write very broken software and don’t seem to care about the damage that they do.
• GC
• Template Haskell. It leads to dark corners.
• Poor tooling and animosity in the community.
• There is nothing like scikit-learn: An easy to use, well-documented, 1-minute setup machine learning / data science toolkit with all the functions you need for the 90 % use case. Instead we have people reimplementing numerical towers (where numpy is successful in ML with just 64-bit floats everywhere) or making dependently typed but CPU-only neural networks. Binding to python doesn’t really seem to make sense (wouldn’t that hurt speed a lot?), so it seems like a big undertaking to make something even half-comparable to scikit-learn, but it could also mean a lot for Haskell’s usefulness in data processing.
• It is hard to get into it. So many won’t.
• Compiler errors are often vague and unhelpful.
• Shitty records.
• Learning curve
• Libraries are not always of good quality. There is a lot of fragmentation in the ecosystem (i.e. competing libraries, for instance regarding streaming libraries). This makes the situation worse.
• Community infighting over build tools and ecosystem issues
• Lack of cohesive, declarative statements from leadership to help guide community action (see: Rust)
• reddit.com/r/haskell
• String/Text/blah problematic, old record handling, sometimes its hard to reason about performance and memory.
• Reasoning about performance is non-trivial. Knowing when and how to make trade offs with design decisions is something that comes through (sometimes painful) experience.
• Elitist vibes from parts of the community
• Template Haskell.
• Lack of good editor tooling, records
• Debugging, stack traces, finding where is my program hanging.
• All that unfortunate TOOWTDI moments in it’s design type classes instead of ml-like modules, but not both (fixed)
• do-notation instead of monad comprehensions, but not both (fixed) simple records instead of t-rex, but not both
• No mainstream binary distribution mechanism (Nix counts, I guess, but it’s not integrated into Stack/Cabal).
• Lack of unification over build tooling
• Terrible tooling, constant community negativity circlejerking
• Difference between code and execution
• Dependency massaging
• Impenetrable compiler errors when using some of the more advanced libraries (lens, servant, and anything doing a lot of type level programming)
• Too much category theory cosplay in the community (and I’m saying this as a mathematician who finds category theory very useful to programming!). Not enough focus on what really matters: that Haskell is a good language for writing maintainable programs that run on computers.
• Records.
• Hundreds of extensions.
• Understanding the application of a lot of language extensions. There is a dialect of Haskell for everyone making it difficult for beginners.
• It’s community
• The record syntax. I haven’t learnt lenses though.
• Public mud-throwing between prominent members of the community about personal spats, or when prominent members of the community hint at “toxicity” or some such nonsense. Nobody cares, and I do not want the community to become polarised into political camps. People should work out their own problems with each other, in private, ideally in person.
• People like to invent a lot of DSL’s on top of “Vanilla Haskell”. I know it’s very useful to do so, but also makes it hard to get to learn and use new libraries.
• lack of nested modules/subsections (like Agda)
• hard to get paid for it
• Compile times
• Slow compilation, restrictive module system, messy base package.
• The lack of libraries to achieve what I want to do, and lack of direction in how to approach certain problems, because of no resources on how to do so.
• Debuggability; (relative) lack of adoption.
• Having to understand how to “glue” some libraries together VSCode is not working consistently.
• unusable as a large scale project
• Compilation times, cryptic library documentation subpar editor integration compared to other languages.
• Some simple tasks become overly complex (like updating a nested record, duh)
• The syntax, the complexity (too many ways to do the same things)
• The lack of broad consensus on how to do things, best practices, and general standards.
• I am still learning, so I don’t have a strong dislike towards anything specific.
• Given that you can learn so much all the time, it’s easy to not get anything done
• slow compile times, not-really static static binaries
• Haskell should make it easy to write static analyzer and refactoring tools, but there is no proper IDE that gives us all of this.
• bad faith dipshits (de goes, snoyberg, morris), my way or the highway attitude, etc
• compile times
• Sometimes feels like too much magic, also the compiler is fat and slow
• The cultural attitude that type signatures are more than enough documentation. There are many different ways to write Haskell, some of which are easier to read than others. Don’t force me to read every line of your library to understand what it does.
• So hard to onboard new people at work, libraries are hard to understand/explain
• Laziness, compiling speed.
• Slow compilation speed, slow binary startup cost, slow interpreter. Honestly considering learning OCaml to use as a scripting language for this.
• I think the community looks bad when we use fake implementations of algorithms like quicksort to make Haskell look better than it is.
• Ecosystem needs a lot of work
• No printf
• laziness
• I really disliked the schism caused by projects like stack and the fights that happen on social media and reddit (I stopped reading reddit r/haskell). I lost all sense of “community” at that point. I wish people instead resolved their differences and worked to make cabal-install better. Indeed it became better, I think, because of stack, which was a nice “side effect”.
• Obtuse documentation
• Being able to find a role as an intermediate levelled developer. Most of the industry always asks for senior level which can’t entise newcomers as the goal of working as a haskeller full time is a very hard task.
• It is high time we stopped using String everywhere in the stdlib, including for FilePath.
• The FPComplete/Stack communities are highly opinionated, political, and anti-competitive when speaking about other libraries. Michael, Taylor, or Chris, if you’re listening, you really need to introspect on your behavior.
• People don’t know what it is.
• Matrices aren’t really a solved problem, probably needs a typechecker plugin
• The compiler performance.
• It’s very hard to find companies that use it
• Tooling. Lack of progress on language standard, which means that we have to use a lot of default extensions instead.
• Compilation errors can be hard for beginners, and as a tech lead and manager I often see newcomers struggle.
• Debugging
• build times can be slow
• Community politicking.
• Performance Optimization
• Language extensions
• Confusion.
• Lack of libraries.
• transformer stacks
• We have serious problems as a community at the moment. I wish I knew the answer, but it would be great to see fewer reports and examples of harassment, elitism, and bullying by high-profile members of the community.
• I’m not a fan of how the community makes really, really complex solutions to some problems and then considers that problem solved. How easy is the solution to use? How easy is it for newcomers to learn? How maintainable is it? Is it well documented besides this blog post that is going to go out of date?
• Absence of record overloading
• The date and time libraries are an embarrassment.
• Lack of users where I live
• Bad errors, bad naming, too many concepts that are explained badly and thus become hard to understand.
• GHC is a sort of “bottleneck”, e.g. it’s hard to even parse a piece of ‘real’ Haskell code without it (e.g. due to different mixtures of extensions, especially CPP and TemplateHaskell). I think this makes tooling harder than necessary, both to develop and to set up for users.
• The community, since 2015
• Lack of jobs, long learning curve, and resistance to adoption makes learning Haskell less valuable than learning C++ / Ruby / Scala, regardless of how much better it is.
• Build times. Tool fanaticism.
• Libraries come with serious cognitive overhead most of the time.
• It can be hard to understand what current best practices are. There is a great deal of tribal knowledge.
• The learning curve, and how much you need to maintain in your mind to become productive
• Having to do a lot of tedious and noisy casts between numeric types, eg using fromIntegral and realToFrac.
• I’m starting to hate the use of String by default
• The tools are mediocre (Stack is OK, but e.g. haskell-mode is very brittle). Much Haskell is impossible to analyse without going through GHC’s API, and the prevalence of Template Haskell means that this might require running arbitrary code.
• IO
• String/Text/ByteString
• Monads. I hate monads. No one understands them in a way that can be easily explained to newcomers.
• Too easy too write non-performant code
• To get the best performance I often have to compromise writing idiomatic code.
• That it doesn’t have great leadership / community.
• It can be very difficult sometimes to figure out how to use a library when there is little documentation and no examples. Luckily, I’m encountering this problem less and less these days with many libraries, especially the more popular ones, having very good documentation.
• in the 6 months i’ve been using it, it appears to be completely impractical for production apps. incomprehensible documentation, there appear to be no best practices that promote ease of working in the same code base as other developers, editor plugins leave a lot to be desired, significant whitespace was a weird choice. as far as i can tell, the small community spends most of its time on keeping up with the latest in computer science instead of making it useable.
• Lazy evaluation and GHC’s monopoly.
• Strings and records.
• I guess it would be the editor. I hate want to easily navigate to source code (both mine and libraries). I want to easily see type info etc
• tooling
• The build stack
• Bottom inhabits all types of kind *.
• haddock is not enough for most libraries
• The hacks we currently have to do to in advanced type-level programming.
• I wish there was less skepticism about using it (from people outside the community)
• hard to learn and teach — tools need more love
• laziness
• No best practices, tooling is still not optimal documentation often missing the ecosystem.
• Formatting.
• Package install speed
• The documentation is sorely lacking in some areas and the setup is confusing (due to multiple competing options) making it a hard sell when introducing new people to the language.
• singletons
• terseness, library documentation, best practices difficult to grok (maybe just too different from typical imperative languages), development environment
• Difficulty finding a haskell job
• Records
• Exceptions. They ruin everything, and make it impossible to reason about pure code even. We get all of the downsides of exceptions, even though Haskell’s type system has far far better tools to deal with runtime errors.
• The right approach here is to have fail-fast fatal errors, and use Either for everything else.
• learning curve
• IDE integration, Run-time introspection (debugging)
• Binary sizes
• badly sampled surveys
• While I’m grateful for dependent types being worked on, the current implementations feel quite hacky at the moment.
• The lack of good development tools — particularly on Windows.
• Two decades of academy-only use, documentation in academic papers
• The drama in the community all the time. You know what I mean. Really hurts the language.
• haskell.org
• Records are a pain, and a lot of our extension usage boils down to working around not having extensible records
• Lack of community activity around making mundane, simple things. Too much community activity around flashy intellectual topics.
• I guess that it’s difficult to reason about its performance because of its laziness.
• Cabal proponents are adamant about how Stack is destroying the community
• Too difficult to train new Haskell developers.
• needs more monads
• Difficulty
• It’s hard to learn.
• I cannot get GHCJS to build!!!!
• Cabal and its fanbase harassing Stack users. I just wish they would go away.
• Lack of libraries for rarer algorithms. No Rpoly for instance.
• Strings and tooling
• Limited data science/analytics ecosystem.
• Divisiveness in the community. Stack vs Cabal is a good example. There’s no need to complain about every bug or issue in Stack just because you don’t like Stack. It makes the community look bad and hinders outsiders because when they ask questions about the differences between the two they start a flame war on accident
• Laziness by default
• The use of laziness by default and GC.
• Which library do I use for X? Is it popular and maintained, or abandoned and out of date? How do I get started with it? How do I construct values for it? How do I get values out of it into some format I can use? What do I need to do to get this in the right String/Text/Bytestring representation?
• Community defensiveness towards the status quo standing in the way of improvement.
• The steep learning curve coming from an object oriented background.
• community infighting
• how old some code is in prelude. the difficulty of understanding best practices. the lack of consensus on libraries.
• It’s not that easy for me to find good examples of best practice things for code deployment, project maintenance and other “practical” things associated with use in production environment. ThreadScope is more or less impossible to get built, and I find debugging logical errors challenging (probably due to my inexperience though). A stepping debugger would have helped even if it’s hard or not possible to build one, don’t know.
• Community fragmentation
• It’s very hard to learn after 20 years of imperative programming.
• can be difficult to solve some things on your own when you get stuck. there are some sharp corners in the language
• the outdated prelude (e.g., how [] is still syntax reserved for lists and how String is still [Char])
• Useless infighting in the community.
• Compiler performance, especially with template haskell.
• More a GHCi thing, but the debugging user experience needs work.
• tooling
• The library ecosystem generally takes little care to use dependencies sensibly, often pulling in lenses plus 50-ish other random dependencies “just because”. Writing overly complex code is often idolised.
• The community. It has an elitism problem and a well-known subset loves to apologize for or host fascists (the lambdaconf crowd).
• language quirks such as needing extensions for every file. its becoming a meme…
• The attitude and behavior of some core tooling contributors. The fact that GHC has a idiosyncratic development process (understandable though that may be).
• The lack of a go-to documentation/learning resource, similar to what the Python community has or even the web development community with MDN’s efforts.
• Effect typing
• Lack of 3rd party packages
• The runtime and the compiler.
• Fragmentation in the ecosystem, inconsistent attitudes toward failure, lack of like-minded people that care about running reliable and highly available systems, exceptions thrown in libraries, Michael Snoyman and FP Complete still taken seriously, community still overwhelmingly white and male even compared to other tech circles.
• The lack of widespread adoption, sadly. It’s hard to distribute Haskell programs to non-Haskell programmers.
• Difficult for newcomers
• Community infighting over Stack
• understanding how to write high-performance programs, debugging lazy evaluation
• From a language standpoint, purity (while usually great) can occasionally be annoying when you have to thread everything through a monad in a way that sacrifices code clarity.
• Laziness can also be troublesome when trying to reason about the behavior of code.
• lack of records.
• Oh dear God module imports, having many libraries imported at once leads to module hell of the worst variety, especially as Haskell is unable to decipher which instance of some common function I’m using from the surrounding types.
• cabal
• Trying to find libararies, examples of best practice, and get my head around the strong safety it requires.
• People thinking it’s the same thing as GHC
• Learning curve is steep
• Poor documentation. A culture that fetishises overly terse code, poor naming conventions. Hard to reason about lazily evaluated code. Default strings are not performant. Operator overloading makes for confusing code.
• Dealing with records, especially after trying PureScript. Maybe also a lot of cruft in Prelude (e.g. partial functions and String) that then are used pervasiely in many libraries as well.
• It took a long time to get used to using . () and $ to make my functions execute in the order I wanted them to. A visual representation would have helped immensely.
• It’s weird
• Documentation lacks examples; tooling is very hard to set up.
• I think Template Haskell perhaps — even though it’s mostly quite good, there are a bunch of things about it which could use a bit of rework. It would be nice to be confident that reify would always produce a complete definition. It would be nice to have a newName-esque thing that produced names that were neither capturing nor capturable. It would be nice to have a pure version of TH that was guaranteed not to carry out real I/O at compile time, since that covers probably 99% of all my use cases anyway. It would be nice for tools like GHCJS not to have to fire up node.js instances to evaluate TH splices. Cases where the host and target would disagree on how a TH splice evaluates are in my experience extremely rare, and would usually correspond to bugs.
• If we’re going to have this target-dependency, we should at least be able to turn arbitrary values at compile time into values at runtime without the need for something like the Lift class to turn them into syntax, i.e. It would be pretty cool to be able take a closure on the heap during TH evaluation and translate it into a corresponding closure for the target which just gets loaded directly. This would be useful for doing compile-time evaluation in a general way, or just packing Text and ByteString values into your executable.
• The lack of high-quality tooling and the monolithic IO construct
• exceptions in base
• No good way to deal with orphaned instances.
• Laziness by default. Laziness is great, but I think Idris’s approach of strict-by-default, easy access to lazy, is much better for predictable performance.
• Laziness is sometimes annoying
• The widespread use of cryptic operators
• Too many features and too much cruft
• Bad tools and getting worse. People who get too esoteric about the language and give it a bad name. Difficult to detect space leaks, easy to accidentally create slow code in certain situations.
• Lack of “default”, proven libraries for “boring” tasks like XML parsing. Lacking IDE support compared to other languages like Go. No “decent” GUI libraries. …
• Too divergent practices for effects.
• Large design space, leading to indecision Lack of high performance numeric libraries.
• Long build times when depencies haven’t been cached yet.
• Tooling, Compiler performance
• Records
• stack traces
• String type and divisions in Haskell tooling.
• Binaries are too large.
• I/O, but that’s probably because I don’t yet understand it well.
• Understanding performance.
• A culture of not caring about bureaucracy and tedium in tool use
• Management of name spaces.
• Documentation is poor, lack of dependent types
• elegance
• Lack of libraries & documentation.
• The tendency for people to make things unnecessarily abstract/general in Haskell.
• The lack of good, built in records (e.g. I would like anonymous records with row subtyping, and the ability to easily reuse record field names).
• The drama that occasionally breaks out between the Cabal and Stack camps.
• Standing up an application still feels like an unnecessarily intimidating task; I would love to see an “opinionated” framework like Spring in Java, which lets me just something slammed together with minimal effort. This provides a much easier jumping-off point so that beginning to intermediate users are not scared off by the need to understand monad transformer stacks; it can be abstracted away until they build up an intuition for it. I have personally felt like I could not even get started with a larger project until I’ve seen many examples and blog posts of the ReaderT (etc) pattern in action.
• How annoying it makes fevelopment in most other languages.. (compared to haskell)
• The record/row situation
• the meaningless Data. and Control. prefixes for all the library namespaces.
• The String issue
• Libraries are often not well documented.
• There is tremendous amount of infighting and mistrust among senior members of the community. Haskell is not going to succeed with such distractions.
• The tooling can improve a lot especially editor integrations.
• Best practices documentation is very sparse. That makes it extremely frustrating to move from beginner to intermediate levels.
• Elitist stigma
• Default strings
• Lack of quality numerical libraries. I keep having to recommend C++ and python to people interested in simulation, linear algebra, data science, machine learning, etc. because they’re just light-years ahead of us.
• Ridiculous flamewars about stack and cabal and so on. Only a few people care, but it poisons the whole community. A number of Haskell newbies at work have been put off enough by this to complain about it.
• The lack of world-class data analysis libraries, like Python and R have.
• Poor documentation. Types isn’t enough: they only givr you the what, not the why and the how.
• It’s hard to be productive when I have to learn too many new paradigms at once.
• Easy to break if you don’t stay on top of the configuration.
• laziness. Not because I think it is bad, but because I don’t fully understand what the benefits are. It seams like a lot of things in haskell are bad because it is lazy by default. For example when people talk about the implementation of the runtime they call out laziness as part of the reason why it is complicated or heavy weight. Really I just don’t understand why being lazy was such a big deal except for a few examples here and there, but those examples don’t seem like it is all that big of a win. Like I said maybe I just don’t know what the benefits are, so I see laziness as stumbling block.
• The community is filled with egotistical superior-feeling snobs, I’m not joking.
• Performance
• Lack of documentation of complex libraries
• The “community”
• Cabal and related tooling
• It’s hard to get into
• So far, trying to understand why seemingly innocuous changes cause unexpected behavior; rare but difficult to debug SDL (graphics) apps when this happens, as I’m not a Haskell or SDL expert. Currently I suspect monad transformers.
• It’s very hard to convince people at the workplace to use Haskell for an upcoming project, largely due to the steep learning curve and the “not good at solving real problems” reputation. Perhaps this can be solved in time with better learning materials and more success stories.
• Lack of common approaches amongst libraries. Things look good if you look at the libraries from a particular author things are consistent, but some libraries are well off the deep end and seem to be someone’s hobby horse abstraction. Some consensus around best practice (e.g. everything should be built around mtl style classes) would make integration various frameworks a bit simpler.
• It has a very different performance model than most other languages, thanks to non-strict evaluation
• Build tooling.
• Performance is abysmal, unstable between releases, and unpredictable. Libraries are hardly documented with almost no examples. The error messages are nearly useless and a complete mess.
• Compile times.
• The tribalism and BS politics that have gone on lately.
• Drama
• The lack of practical efficient extensible records, and the multitude of options that try to solve the problem that for some reason don’t seem to be the right solution. Is it because the community hasn’t clearly adapted one of them?
  Further, this might be one of the reasons why Haskell feels a bit clumsy for some data-mining, machine learning and statistics related tasks.
• The amount of time spent compiling.
• Package installation time.
• Relative isolation of its programming community from others. Not enough ahared terminology. Haskell community seems insular.
• Laziness, compiling takes too long
• Huge learning cliff to scale
• The Stack vs Cabal war.
• Interpreting errors.
• Records
• It isn’t dependently typed
• The learning curve that took me several years before I was comfortable enough to start building a real application.
• Drama in the community.
• Poor support for namespaces.
• I wish libraries gave actual examples of how to use the code in documentation… that basically never exists, which is very ‘pure math-y’… lots of theory, little worry about real-world application, which could be very simply communicated through a simple example. Functions and types only give a description of the inputs, outputs, and a story of what the function does. This is very often not enough to communicate how to use the library. Could be very simple to communicate through an example.
• Records
• The tooling. I have never succeeded in configuring Emacs to handle GHCJS and GHC, and never got auto complete up. Have been managing with just syntax highlighting and ghcid.
• Performance
• I think my gripes are in the compiler, RTS and performance, and less in the language itself.
• Compile times can get really long. I occasionally write games and garbage collector basically murders them. I’m restricted to either 1) making all data GC-friendly 2) making games that are so simple and use so little memory GC doesn’t matter. I wish I had a choice of a different garbage collector. I would sacrifice throughput for low latency times. I heard that linear types are coming but I am skeptical it that feature would help me, even if I had safe resource allocation and deallocation.
• The performance of the code produced by GHCJS is terrible. I think most people don’t care; but imagine my problems with garbage collector that I described above and now make it run on JS. My benchmarks typically show 20x performance hit compared to native code on some gaming-related benchmarks. I wish either GHCJS would get more performant or Asterius WebAssembly compiler becomes practical. (on other hand, I think it’s absolutely amazing GHCJS can compile so much of Hackage to the point I can almost confidently expect any given package to Just Work(tm)).
• Multi-core performance at high number of cores (32+) seems to be bad. I have these machines at work. The solution is usually to spawn more processes instead of Haskell threads. My Rust friend laughs at my crappy multi-core Haskell program and it makes me sad :(
• lack of stable and good GUI libraries
• As a very new functional programmer the threshold for getting into functional programming language is quite high when coming from imperative object oritented programming.
• Worrying about bottom/exceptions lurking in libraries.
• The build-tool “wars”. I would personally prefer if everybody just settled on stack.
• Lots of Haskellers eager to theoretical side and forget about purpose of their project.
• So many things to learn, about type system, compiler, etc and different ways to do things that it seems i would never reach a deep level of understanding of the language. Sometimes i feel i would need 15 years to master the language.
• too many competing overlapping libraries, performance is difficult to optimize and even specialized numeric libraries (e.g. Accelerate) are much slower than the equivalents in c++
• How it can start to look like Perl at times.
• Hard to become proficient and productive
• Debugging and execution tracing/transparency.
• Still hard to reason about laziness, and to do memory debugging. Still bugs in 8.4.3 such that biographical profiling is plain broken.
• Immature tooling (packaging, editor integration, etc)
• Binary size. Laziness, boiler plate, no namespacing
• Real IDE lacking
• Lack of dependent types and contracts and stuff, and the build systems
• Hard to get into. It takes a while to learn it and all the tooling yo feel comfortable.
• We need more people using it in the industry.
• Its userbase is kind of homogenous.
• Getting things to build
• Operators. Library documentation is a close candidate.
• The many special symbols, as they sometimes are confusing for beginners, especially when combined.
• I’d like to see StrictData be on by default (but that’s a huge change that I couldn’t really recommend).
• The way record syntax works and easily causes name collisions.
• Tooling
• Hellish type messages. Debugging. Web.
• Bad package manager
• Ecosystem, tooling
• Debugging
• Preprocessor. I have strong opinion that preprocessor is responsible for our current tooling situation. Basically, presence of preprocessor takes away the ability to parse arbitrary Haskell code. With it, in order to finish parsing the tool has to know about build system and current build flags/#defines. This significantly raises the bar for tools and still takes away the ability to produce single AST capturing the program structure that other tools can work on. I.e. with preprocessor the tool can ask the build system about flags, run preprocessor, finish parsing and produce an AST, but if, say, rename refactoring acts on that AST then it will newer see the parts of program that were disabled by the preprocessor and consequently will not do any renamings there.
• The editor tooling is bloody awful
• Long compile time and dificulty regarding predicting runtime performance that results from changes in code, libraries and compiler versions.
• Lack of jobs for someone in my position. I’d like to go further but I feel like I really need to be using it full time instead of here-and-there as a hobby thing.
• Tooling. The lack of a stable API to GHC makes writing tools hard. And the bickering about build tools doesn’t help anyone.
• RebindableSyntax and ExtendedDefaultRules are completely rotten. We need more flexible and composable framework for changing semantics.
• String type and Records.
• Tooling
• Tha education gap between tutorial and real world app dev. It feels as if I have to get all aspects right (like logging) at once because afterwards it will be hard to add it in
• monads
• Lots of work navigating/moving code, managing imports/packages, refactoring/layout editing
• Libraries
• The difficulty of reasoning about the effect of compiler optimization.
• Proliferation of syntax extensions
• syntax
• Despite what i wrote earlier, limits of type system can be frustrating, particularly unlifted types, and sometimes dependent types.
• Fragmentation in tooling and willfully cryptic documentation for major libraries. For the other things I usually blame myself.
• debugging performance
• Performance optimisations can be fragile. Low-level programming could be supported better.
• Compilation times, lack of library docs.
• length of build time
• Heavy compiler
• I wish there was a easy way to express anonymous sum types, kind of extended Either.
• It’s tricky to optimize Haskell code (cpu time, memory consumption) for production uses (applications, middleware).
• Reduced instant gratification vs. other approaches.
• Library documentation very frequently commits one or more of the following sins:
• using single names for type variables without dropping any hint as to what they mean
• expecting you to read a paper before using the library
• providing functions without hinting at why you might want use them / what problem they solve
• providing functions without examples of their usage
• providing data types that don’t explain how you might construct one or how you might use one once you’ve got it (this is I think one of the unacknowledged strengths of traditional OO languages)
• I think a lot of this is a function of tooling. Plenty of Python libraries have great documentation because they use Sphinx (e.g. https://www.attrs.org/en/stable/, which was itself inspired by Haskell). Likewise, https://doc.rust-lang.org/std/ is much nicer for me to use than Hackage.
• Vast quantity of unpronounceable and difficult to remember operators
• Debugging and tracing what the hell is going on when things go bad.
• Too many language extensions, overly abstruse walk-throughs of code, records suck, the string thing.
• Without benchmarks performance isn’t always easy to predict.
• I would like to have more easy metaprogramming, like traverse the fields of a record in a more simple and easy way.
• complex. Exploratory, experimental. snobbish,There are no established how-to’s
• its unrealized potential due to historical baggage
• Still not that much support in editors / IDEs. Also single-stepping is sometimes hard.
• Dependency management
• performance visualization math
• The size load of dependencies is huge
• Lack of data exploration tools
• Dang its hard to learn.
• Lenses
• The bad apples in the community that bully others.
• Compile times, sadly. And proliferation of language extensions.
• I think the error messages can be cryptic; but frankly that’s because the language is more powerful than, for example, Elm. Elm knows more about the programmer’s intentions — hence the better error messages — because there is less that the programmer can do.
• not at all unified. Everything is always redesigned from the bottom up. Not product and result oriented.
• Laziness by default: the bane of reasoning about performance. It takes an expert to dig into and understand issues caused by laziness.
• Significance of white spaces.
• It is hard to write the code.
• Cabal
• Debugging
• Space leaks can appear without warning. Not as easy to debug as Java/C++ etc.
• Laziness.
• relative difficulty of advanced techniques
• cabal-install
• coming from Java, it’s not easy to learn
• the runtime is big, binaries are large, compile times are long
• Laziness in terms of performance, makes some issues at run-time non-trivial to debug. Hard to know how to optimize code sometimes.
• High complexity of some libraries or concepts, many times these have a solid theory behind. But in many occasions not everyone has the time to read papers to know how to use certain features of the language/libraries.
• Profiling should be even simpler.
• Type safe
• Debugging, memory leaks
• Dependency management.
• I can’t convince my employer to let me write in Haskell.
• The advanced type system
• If you’re in a typing pickle. It can be a bit tough sometimes to reason about and find a solution to. (muti stacks of monad transformers)
• Compile times
• High learning curve, unclear documentation, stack vs cabal vs how to start, lack of people that see its beauty
• Documentation.
• Records, state of data structure libraries, type errors from lens
• Fancy types and languages extensions can create very confusing and complicated-looking code for a new person. IDE and development experience is far behind other more mainstream languages (ex: Java, TypeScript).
• It’s a nearly impossible to recommend language offering almost no practical advantages in my field of work (automotive and industrial middleware).
• Lack of any in-editor support tools that are up to date. Dependencies breaking with nearly every GHC update.
• Slow toolchain. Long build times.
• The lack of adequate documentation (in my opinion)
• See ‘Thinks I would change in the Haskell language’ above.
• The lang defaults go against professional best practice.
• sometimes you just want to learn how to do things properly instead of all the theory behind it. hard to find or verify simple usage explanations or best practices.
• The lack of debugging possibilities especially when linking to libraries written in a different language. The lack of a good linker for C++.
• Libraries which develop idioms that diverge too far from the lambda calculus, such as lens or conduit.
• Tooling, IDE, Emacs
• Nested records
• There’s still a lot of ceremony around setting up best-practices, and many ecosystems do not play well together. Some things are practically impossible (eg: hard-realtime, memory layout, high memory tasks, etc.) which need not be.
• Haskell has a very high abstraction niveau. That makes it hard to learn the concepts used in code. I do not understand lenses at the moment, to be honest. But I undestand monads :)
• People at work think that I’m a freak for thinking that it should be adopted at a larger scale.
• That I need to run benchmarks after literally every new line in project. Sometimes just simple refactoring can totally change performance. Basically Haskell would be my dream come true if I could use it with confidence for real world applications and those require high performance. Now this is the biggest problem we are struggling with.
• No decent IDE (like Visual Studio or IntelliJ).
• Unfounded reputation of arcaneness
• I don’t think theres a whole lot of support for Intermediate Haskellers to make the next leap and level up (though it sounds like there are some books on the horizon to help this). I don’t know how to navigate the plethora of language extensions (what are the consequences of using some over others?)
• Debugging memory leaks, debugging with laziness, ghc’s performance limitations
• Packages are not trustable (some) and not well tested
• Some concepts are not intuitive and barely become easier over time
• Tooling and records
• The order of the arguments for foldl/foldr/foldM (it’d be cool if the function was the last argument, so I don’t have to use parentheses or a let/in to specify my function)
• Difficulty finding work in haskell as a junior
• See my favorite thing about Haskell
• Community division.
• Records. 90% of the work I do involves simple CRUD applications, and the record system in Haskell is truly shite.
• There have been improvements with some of the new extensions, but ultimately I still feel writing CRUD code in Haskell is far more painful that it should otherwise be.
• Lack of easy to use GUI frameworks
• straight up: give me a good GUI/Graphics library.
• Lack of good IDE support, Cabal.
• database libraries
• Default import behavior conflicting with global namespace
• laziness that is hard to control
• Atrocious support for programming in the large
• Polarisation over things like build tooling
• Obscurity
• No easy-to-use debugger like ones in Intellij for Java
• Laziness by default. I think the trade-off between making code often a lot more performant at the expense having a more conceptually challenging performance model is not obviously worth it. I’d rather have more direct control, and manually enable laziness where I want it.
• It can be very difficult to get libraries with external C dependencies (SDL) to work properly
• build performance
• Compile times
• Lazyness and that the runtime cannot be controlled by the program in a safe way.
• The class hierarchy is so big and often uses so abstract names that it become difficult to use. Especially all the operators names. For people that are not from the academic world it’s a big turn off imho.
• I wish things were more like Elm. Not language wise but community and documentation, and tooling, and error message, and support wise.
• How records are implemented
• Documentation
• Hard to predict performance Sometimes hard to understand compiler errors
• Lenses.
• As a beginner, it takes quite some time to get into it. But I am willing to do whatever it takes.
• Some concepts are quite difficult to grasp and can be intrusive. Causes are due to lack of well written documentation for beginners and non mathematics people
• It takes a long time to build projects with a reasonable amount of dependencies
• Do syntax
• Build times and binary size
• Lazyness, it makes programs awkward to reason about, and where needed can be trivially implemented in a strict language. There is no benefit to it being the default
• performance issues
• How all the Haskell beginners seem to be fluent in another language already. This really shows in a lot of guides. Meanwhile I have to learn Haskell as my first language and often feel lost even among other “beginners”.
• Error messages.
• Haven’t heard it be spoken in praise, so my least favourite thing is the pop-culture influences not even having a clue for what the language invokes in the user’s programming. I mean: “Why use Haskell when there’s C? C means objective oriented programming — that’s the greatest thing ever!” “Why though? Why use OOP and not anything else as de facto standard?” “Duh… what else is there?” etc.
• The breadth and uniqueness mean that despite long term educated investment, I feel my capacity is well under best practice. This depth also leads to ‘single element’ instruction: the majority of learning resources illustrate feature by feature, and so do not present a full image of well written performant Haskell.
• That the community has a reputation for infighting
• Community drama
• Syntax with all the extensions is a mess, much like C++ with all it’s features. Haskell Prime needs more love.
• Lack of mature libraries for the big data ecosystem.
• My capability for endless bikeshedding given the power / breadth of implementation alternatives. Incompatibility between libraries (e.g. incompatible error handling or representations) — I see this issue with most languages who have a small std library (e.g. divergence in time handling, calendar handling, error representation and handling, etc etc).
• Tooling, maybe lack of libraries?
• type Errors ;-)
• The tooling especially editor integration. The sparsity of examples in documentation doesn’t help either.
• it’s hard to write really performant code (think: implementing core algorithms). Support for working with graphs sucks.
• Unpredictable performance
• performance
• Debugging, tooling, and overcoming the bias (some fair, some unfair) that people outside the community have towards those in it, and vice versa.
• Some compile errors are too hard to decipher
• The community has gotten a little toxic
• Absence of good modern literature on the subject. I don’t need “a beginner’s guide to Haskell”, but rather “Effective Haskell”
• portability, pachakes search
• The political activism
• It hasn’t been standardized/simplified/cleaned up with changes like ScopedTypeVariables, MultiParamTypeClasses,etc.
• There are lots of generalizations that should be included by default that would simplify the language overall
• Difficult to shut up and stop proselytizing
• Cabal hell
• Base hasn’t kept up very well at all (missing abstractions, overly specific types, partiality) Have to enable lots of extensions The top-level
• Occasional community elitism, the sometimes weird political underbelly, etc.
• Poorly documented libraries, documentation explaining the libraries it often out of date, examples don’t compile.
• Hard to debug, hard for me to find information about the current best ways to debug
• Profiling
• The increasing bloat of the language. Poor support for windows, Have burned hours trying to get GUI tools to work. There seems to be a drift towards assuming that people use stack
• community
• Debugging and profiling. Hard to find memory leaks
• The level of the average meetup atendee is too high for me to be able to feel as part of the community
• String
• Dependencies
• All of the new pain and suffering that shows up — the complexity of using libraries that use complex combinations of intermediate-to-advanced features and are great once you know how to use them but super painful to learn (especially when they are usually poorly documented if documented at all beyond type signatures) and painful to debug when something goes wrong.
• Lack of tooling for things that should be possible to automate. Automated refactoring — with good performance — was a thing in the Java world even as far back as 2001/2002, with tools such as Eclipse and IntelliJ able to automate away most of the tedious drudgery of renaming identifiers, moving definitions, changing parameter orders, extracting functions, inlining definitions, and optimizing imports.
• Of course, GHC gives great feedback, which is a boon when refactoring, but much of the work is still very manual. If I do something simple, like move a bunch of functions into another module, I then need to spend time fiddling around with imports and recompiling. Slow GHC compilation times makes refactoring even more tedious than it needs to be.
• base has many historical warts that need to be resolved. One example is the overlap between Applicative and Monad (i.e. pure and return). Additionally “map” and “fmap” need to be merged to just “map” amd get rid of the List-specific map function. These things are VERY important because when new people come to Haskell it makes the language seem unorganized, messy and that everything is an afterthought. They are not going to care about the detail tbat is is a library issue and not an actual language issue.
• Mostly how optimizated Haskell feels different from idiomatic Haskell. It feels kind of bad to dismantle this nice composition of functions because of some issue with laziness or whatnot.
• Often times I find it very difficult to know when to use operators or functions in order to implement the program logic. It’s not very obvious in many scenarios how to continue.
• http://hackage.haskell.org
• The record system.
• Simple calculations can be cumbersome (eg fromIntegral)
• Probably records and char-list strings. Considering the how bad they are (not extremely bad, but pretty painful) and how often you need to dealt with them (basically all the time, everywhere), they are probably way up there as the most annoying things.
• Managing my imports and dependencies, especially when authoring a new package
• Steep complexity curve with programs.
• Tooling — hard to get started and going
• Windows support on many console based UI libraries is lacking.
• Low adoption, lack of native 3rd party libraries.
• Debugging and profiling could use better tooling.
• Purity and laziness
• Build times, and build size is something I think about. There is something to be said for those things being a(nother) barrier to adoption inside a company that primarily uses other tech. If I’ve built some webapp and would like a front-end developer to contribute, having them install/compile for 20 minutes and it taking 4–5 gigs of space doesn’t sit right with me. Same can be said for a college just curious about looking at a Haskell app I’ve developed inside the company.
• I wonder if there could be some sort of minimal build flag in GHC and Cabal/Stack that could do less work and/or strip out everything that isn’t strictly necessary to just run the app/tests. Could also be useful for CI builds.
• Also strings and records.
• The fact that I’ve been unable to master the language, its toolchains, and ecosystems. I’ve remained a beginner/intermediate.
• The documentation and lack of examples
• Some aspects of community dynamics.
• Not sure if you mean about Haskell ‘the language’, ‘the community’ etc. here so I’ll go with the following: online docs / resource are sometimes scattered in various places, sometimes they are outdated and I often don’t find an easy way to tell. Also, the ‘follow the types’ mantra is valuable 90% of the times but sometimes examples are crucial in understanding an API — especially if a person is new to the language or a given library / framework.
• Old historic stuff that should go away.
• Extensions are complicated — would prefer a new language release which has recommended extensions available by default Also canal is super opaque. Would prefer to be able to build without it.
• Lack of tooling
• Complexity in the community
• People who easily destroy Haskell’s advantages for the sake of supporting bad but common programming habits.
• Too few design patterns mature enough
• Lazy evaluation
• Occasionally hard to read compiler errors, unsafe prelude
• records
• Mentioned above — Cabal/Stack infrastructure. Dependencies can be a difficult and costly to sort out.
• Trying to use new libraries. It is usually easier to write my own (not good).
• Too much category theory and complicated libraries
• Performance analysis, I really can’t do it
• Editor tooling
• The community
• Prelude, lists hegemony
• High quality libraries (in some domains)
• Template Haskell and splices.
• String, and Exceptions handling
• The discoverability of GHC/language proposals and documentation is often not good.
• Few Jobs; Bad IDE Support
• Maybe lack of speed. But if I need speed I recode my Haskell to Swift or C.
• Foldable in the Prelude
• error messages
• Error messages, especially when encountered the first time
• Fixing performance problems, when I have them.
• It‘s a tie between two things that make me hesitate to try to introduce Haskell at work.
• Poor record support.
• Bad defaults (lazy data, linked lists, String) make performant code needlessly verbose and non-obvious to newcomers.
• Monad transformers and other esoterics
• I don’t agree with the common sentiment that the community is aloof or unapproachable, but I think there are too few voices presenting the point of view that Haskell can be a really simple language and actually let you think less rather than more. Most people who write or speak about their Haskell work are coming from the “hey look at this new fancy thing I discovered!” angle, rather than “look how far we can get with just ADTs and functions!”. I’d like to see that angle given more publicity.
• cabal
• I have to spend so time and focus learning keeping up with Haskell specific things that the difference between my crazy type-level/lens-y/abstraction skills and simple, general purpose engineering skills is jarring (ex. AWS, unix tools, dbs, networking). I love my Haskell job, but it seems all Haskell jobs implicitly expect you to have the same depth in all other skills immediately too. Which is rough considering I spent most of time working on Haskell skills and not 95% of other technical stuff (aside from school).
• So many operators.
• Too many libraries, hard to know which ones to use. Very easy to get lost trying to express a program in such a way that agrees with the compiler (can get stuck in situation where I can’t for the life of me figure out why my type classes / newtypes aren’t valid)
• Poor tooling makes development painful at times — haskell-ide-engine uses obnoxious amounts of RAM, ghc-mod seems to have “the impossible happen” to me far more often than it should.
• stepping through code is basically impossible
• how the type system treats record-oriented data as an after-thought
• Figuring out what ‘tool’/function I need to use. I ‘know there’s something out there but in don’t know what exactly it is to search for it. I have a decent idea of what I want but I don’t know how to simplify it enough to do it the FP way
• Its poor namespace handling (unqualified imports by default, extensions such as RecordWildcard which allow putting unknown identifiers into scope…)
• That I can’t use it in my day job
• The ability of both the language and community to make me feel stupid :)
• It’s not popular enough
• Compilation times and hard to decipher error messages (mainly when using data-kinds and lots of type families).
• The despicable behavior of cabal developers and cabal fanatics who stir up drama and try to discredit the survey and attacking everyone who doesn’t denounce Stack
• Steep learning curve
• The need to install external packages and add imports for basic data types like Text, ByteString and Map. I think that they should be imported by default and easy to use, just like in Python and other high level languages.
• Tooling.
• Community wars.
• The shameful anti-Stack/FPC propaganda and personal attacks carried out against Michael and Taylor.
• Compiler performance
• Not very beginner-friendly (community, documentation, ecosystem)
• I would say there is a wide gap from freely available learning resources such as LYAH or the real world haskell books and being able to use even the most comon haskell libraries out there. I haven’t read the haskell book though, as I had already gone through the steepest part when it came out
• String. Numbers. Managing dependencies. Long initial build times. Learning how to use a new library often means reading its source code or test code.
• The community is far from toxic, but many big-name Haskellers are too inclined towards dramatics about how evil certain members of community are (namely, historically, Michael Snoyman); everyone wants to act like they’re the good guy, but it takes two sides to make the drama, and there’s no reason it needs to the top post on /r/haskell every time it happens.
• presence of partiality (undefinedness and non-termination)
• Comparing it to a language like go, building executables or images is slow. I build docker images for all my releases. The compiler is slow and takes a lot of resources. I understand that is the tradeoff from all the things ghc does, but it is a pain point.
• The quality of the available development tools. Emacs integration using intero is an OK experience. But compared to the development tooling for languages like C# (Visual Studio) or Java (IntelliJ) the experience is way worse. Auto-completion is spotty at best, there are no refactoring tools that can be set up in an easy, well documented way that actually works (I’m looking at you HaRe).
• While I have found a way to make this otherwise beautiful language work for me, the development tooling is just so bad, that it can almost be embarassing to recommend Haskell to coworkers. There are a lot of people who won’t touch a programming language that doesn’t have an IDE that works more or less out of the box and I can’t blame them. Haskell has a steep learning curve as it is and the abhorrent IDE situation makes this exponentially worse.
• best practices still being discovered, cross-platform GUI options still suboptimal, want higher-level project-level tools (refactoring, IDE with GUI).
• Records.
• The tendency toward overly abstract obscurantism by members of the community by using far too much jargon.
• Ecosystem too spread out/diverse. Needs ok prelude and libraries that is “main” path.
• undefined
• Vocal minorities causing drama and dividing the community by refusing to accept reality.
• Sometimes I just get completely stuck on type errors. I often find libraries with no documentation. I have never had success with front end stuff (ghcjs, or anything). Complete end-to-end websites with authentication and what not seem to be non-existent (at least with Servant, which is what I use). I often seem to end up writing things that I feel would already be done for me when using other languages. Exceptions in general seem to be a mess because there are a million different ways to do it and everyone does it their own way. Similar with logging. I have a lot of frustrations really, but I would still rather use Haskell than anything else.
• Module system, tooling
• I’d like to see a more aggressive effort to get better defaults, i.e. improve the Prelude, and incorporate a lot of language features into a new standard. I’m used to these things, but for beginners I worry that the defaults don’t guide them in a good direction. It shouldn’t take so much effort to figure out how things should typically be done.
• I wish the tooling was more straightforward.
• (Un)popularity, the need to defend the language and FP framework as a whole, lack of understanding in many circles.
• Changes, FTP
• The battle of the build tools. The lack of interest in ghcjs. The scarcity of clear and agreed on best pracices, for eg. exception handling. The omnipresence of String despite everyone advising against its use.
• String vs Text vs Lazy Text vs ByteString vs Lazy ByteString vs Word vs I DON’T EVEN KNOW ALL OF THEM
• A bit hard to graduate from basics to actually doing something productive
• Lens, parsec. Generally, over-reliance on monadic designs, when it’s not neccessary.
• Boilerplate with string types
• Lack of performance guarantees
• one semantics nitpick: tuples should be true products (not lifted).
• strings! huge pain converting between [Char] (a ridiculous default) and sane bytestring, which isn’t even part of the standard library.
• Libraries poor documentation. Usually there are 4 different libraries that can be used to solve my use case, but all of them have poor documentation. I would prefer if efforts were focused on 1 or 2 libraries so that they would be high quality AND have good documentation.
• Haskellorg’s anti-Stack politics and smear campaigns
• The overall lack of (industrial/financial) ressources/backing to address big holes in the ecosystem.
• Lack of row types.
• poor IDE integration
• Advocacy. The positivity & the plugging seems to ignore lacuane or negatives in the Haskell platform, you end up thinking ‘Is it really just all good!’, and then see this minority of blog posts that point out predictability or maintainability or applicability concerns that none of the advocates talk about proactively.
• It sounds like nicer Lisp advocacy, but I’d rather it be like Ocaml advocacy only more vocal.
• Tooling and eco-system does not compose. As an example, stackage is not inside hackage, hoogle is not inside any other site, editor support is yet not good enough.
• It is very difficult to get into, as many resources are written for an experienced crowd.
• There’s A Gazillion Ways To Do It. I sometimes end up golfing some rather inconsequential and short bit of code back and forth for a very long time while trying to figure out what the most readable (or, sometimes, performant) version is. Also, I have been going back and forth between application architectures quite a bit, because there’s no One Clear Basic Structure.
• From a software engineering perspective, I sometimes wish tests (and properties) and benchmarks were first-class, possibly attached to top-level names, and possibly subject to their own export lists in modules. They are not “just functions”, but rather like documentation they are important facets of correct and maintainable code. I often wish to keep properties about some function close by the function implementation, in the same module. I would even like Haddock to render the properties as documentation, and GHCI to let me access them as properties of exported names (along with the normal documentation).
• It’s not as popular in industry as I’d like.
• Tooling
• Steep learning curve
• Libraries are sometimes not very weil documented. Especially examples are missing.
• Compile times and GC latency
• Editor integration
• EDSLs that produce incomprehensible type errors when I use them wrong. I tried using the lenses library, but it’s so clever I can’t figure out what I’m doing wrong, and that’s not the only time something like this has happened to me.
• Most Haskellers that I come across, are strongly oriented towards being academic in nature, touting about the Type-safety, Monads, etc., but few of them really talk about their practical experiences (such as runtime-performances, memory-optimisations, case-studies, etc., and so always give me a feeling that Haskell still is used mostly in niche areas, although big companies such as Facebook have adopted that (incidentally) in some big public projects.
• Often a very steep learning curve with libraries, since they will often only have type signatures and some brief descriptions. Not enough practical examples, tutorials, etc.
• Type inference and high quality libraries! I just wish they often had better documentation, high level overview and some use-case tutorials (as JS libraries)
• No common view/interface for different collections
• Tooling. Frankly though, my standard is native intellij support for Java, and nothing will ever match that.
• Laziness blehhhhhh
• An emphasis in the community toward mathematical constructs rather than commercial application. That said, this is also something I love, but it can be very overdone and I wish more innovation went into the more commercial side of things
• IO is a mystery; it’s not easy to see why some things work and others don’t.
• some pain to get external data involved
• Bad editor tooling :(
• Slow compile times
• Need to enable 48298 language extensions to do anything useful
• It’s difficult to find where things are imported from
• Adoption
• Exception handling / lack of stack traces / debugging tools
• Stack-cabal war.
• All my mistakes are communicated to me in terms of “Couldn’t match type X with Y” or “No instance for X” by the compiler
• It’s not Agda.
• Steep learning curve
• Tooling
• Library support can be sketchy in some areas (like GUIs), but amazing in others. Windows support is also kind of sketchy sometimes, but it’s getting better over time
• Performance.
• Documentation for intermediate to advanced users.
• Community fragmentation
• Haskell fails in its safety promises, and the tooling makes it unusable compared to other languages. Haskell is the only language for which I have a second desktop, not a VM, to do development.
• Slowness of generating random numbers
• monads, they infest codebases and remove your ability to use the beautiful and simple pure haskell that sells the language. easy to say impure wrapper pure core… but then what about logs? real software typically has logging as it is critical to be able to debug production systems not working.
• the community is toxic and my employer would not be using haskell if we’d seen some of the threads we’ve seen over the last couple years. the stackage-vs-hackage drama for example would have made us adopting the language a hard no.
• Haskellers are often not pragmatic people interested in solving business problems and delivering software. this makes them a difficult demographic to work with in a business setting, as they are prone to chasing type astronaut nonsense instead of delivering the software that gets us paid. it is easy to say they are looking at the bigger picture, etc., however if we don’t deliver we go out of business and their long term stops existing.
• Hard to get into
• GHC is such an understaffed mess of code.
• The packages, while abundant, are often lacking in certain areas such as Game Dev and GUI programming
• There’s no job!!!!
• Being owned by the compiler.
• Package management / build tools.
• Hard to find PhD students to work with the language.
• Inability to review the compiler’s type inference logic.
• Lack of high quality packages (“keys,” “semigroups,” “mono-traversable,” etc) being included in base or in GHC shipped packages.
• Best practices are not well developed and not documented.
• Libraries are often hard to figure out how to use from poor documentation and examples and the types alone are often too complex to easily digest and use without said documentation and examples.
• Too little career opportunity to work professionally on Haskell, especially when you are not in the US or UK.
• Prejudice against people who use “inferior” languages like JavaScript, even when they are interested to switch to Haskell.
• Tooling reliability and the obnoxious attitude of many Haskell programmers.
• Slow compile times with GHC. e.g. 40 minutes on CircleCI vs 5 minutes for some PHP/JS projects (of course, those don’t actually compile but it’s a super important factor for DX).
• The available development environments still feel very unpolished compared to the ones available for languages like Java and C#.
• Reasoning about perfomance.
• Updates (compiler/build system/library)
• Laziness
• Documentation needs to become a lot better, it’s behind compared to other languages. In Haskell I often have to read the source code to understand the docs also.
• The people. The current community.
• very little of the ecosystem is suited for “real” problems, both because many of us working on eg finance and aerospace aren’t in good positions to release and support libraries, and also because others working on “fake” problems (web apps, blockchain) are inherently more visible
• while the language is very suitable for many of my engineering tasks, the general community emphasis on consumer-facing application software means substantially more basic infrastructure needs to be built in house compared to the c++ ecosystem
• How difficult it is to get into certain subjects, like writing web APIs and working with processes.
• The tooling ecosystem and it’s fragmentation. There seems to be a big divide between the stack crew and the cabal crew and I’m just waiting for sanity.
• lack of connection with other communities, e.g. Java
• Reading concise code
• Population
• when making program, I just focus logic. Other language has many noise.
• Build tools situation makes it very hard to maintain libraries. Because of not-welcoming community, it’s not always pleasant to write blog post as usually, people are making fun of you because of various reasons (not perfect English, or usage of some tools).
• You’re not feeling welcomed and you’re not always comfortable sharing your results with the community (blog post, open-source libraries, etc.)
• Editor tool support.
• Slow compilation speed, Buggy build tools.
• Nomenclature
• The way we talk about Haskell’s strengths can make it seem intimidating to newcomers
• For any given industry-defining technology or standard, there seems to be about a 25% chance each of finding:
  1. a mature, well-documented library with great examples;
  2. a library that is full-featured but has some quirky idioms that I have to figure out on my own, guided by nothing but type signatures;
  3. a direct FFI/API wrapper that forces me to deal with the other end’s assumptions, e.g. mutability and weak types; or
  4. nothing, or a proof-of-concept so minimal it might as well be.
• Name conflicts
• Text,string,bytestring = hell
• extremely unproductive: once haskell is chosen, the project becomes a research project into how to best overcome haskell’s shortcomings, rather than just doing the project.
• A large fraction of the community seem to be either inexperienced programmers who haven’t got a baseline to compare their productivity in haskell to, or committed professionals, who have other reasons to lose objectivity.
• let statements in do blocks
• performance
• Reasoning about program performance.
• The base library is not batteries included. Also a lot of really useful, if not absolutely necessary language extensions are not enabled by default. And the awfulness of String.
• Haskell tooling because at least once a year I get a headache with either Stack or Cabal-install. Most of that has happened after Arch Linux has made a change, but I don’t have similar problems in C, Python or even Rust when changes like that take place.
• It’s very easy to get lost trying to make code insanely generic and put everything in the task
• If you need to write real-world app, you need to learn a lot of things (servant, lenses, State, Reader). You can’t just go ahead and write something. You need to really dive in.
• People’s uninformed views of it. Knowing Haskell well should be a huge boost when looking for jobs, unfortunately it isn’t when people don’t know it or think it’s something non-practical.
• The learning curve.
• There is no reasonable way for someone not using haskell at work to learn it without dedicating copious amounts of time.
• I learnt Perl on the side. Writing small shell utilities as and when I need them. It is difficult to contemplate doing it in haskell.
• Records.
• Abysmal performance in some corners of the language.
• Records
• Type system
• Records
• I have to put this here because there wasn’t a box above but for the questions “I think Haskell libraries are well documented.” and “I think that Haskell libraries are easy to use.” I need to say that many haskell libraries are well documented, in the sense that haddock tends to go a long way and allow me to browse and see the definitions of what I need to know about, and haskell libraries are easy to use once you understand how they work. However except for some very basic and obvious libraries like the “extra” package, I tend to need tutorials to understand how to use a library and most don’t come with one. A blog post may help you on your way, and certainly haskell libraries are understandable if you take your time at it, but more need to have tutorials that go over their features and usage as part of their documentation.
• It hasn’t seen much commercial success, so we don’t have a ton of experience reports or job fluidity.
• It’s lack of adoption in big name product companies (except Facebook, but they don’t use it as extensively as say… C++)
• practice of usage of extremely short binding names
• One can pick it up when gets involved in the community, reading up blogs and tutorials. Although, it is a double-edged sword, which has good advantages as well!
• The ide tooling is incredibly flaky and is difficult to setup
• Difficult to tell how performance will act, in terms of GC, what will not really be allocated, what rewrite rules will fire. Free-in-theory abstractions like newtypes impacting performance etc
• Build tooling
• Slow dev times sometimes because it forces you to be very precise.
• Fragmented tooling and poor editor integration.
• Tooling
• Divisive/inflammatory members of the community
• documentation
• Well, it was frustrating to admin I knew nothing before stumping over haskell. It forced me to learn a lot, and it is not finished.
• The barrier to entry which my be hard if said person is used with other imperative/OO languages.
• Editor tooling/package managers
• Lack of (good) libraries.
• People who spit on code of conducts
• Don’t know how to do this, but maybe try to make Haskell just a bit more performant (its already a faster language, but more performance could sway more programmers to give it a try)?
• Learning curve
• While I fully understand the arguments for non-strict evaluation, on balance eager evaluation is more useful to me.
• Stack. Because of it the community has grown increasingly hostile over the past 3 years. It was once the most pleasant tech community I knew, but has now easily lost that title.
• It is difficult to reason about performance.

What Does This All Mean?

So you made it this far through the responses and are still wondering what all that negativity means for the future of Haskell? The good news is that a lot of people do care about Haskell or they wouldn’t bother complaining about it! It’s all good!

In the next post we’ll look at what people liked most about Haskell!