What Would You See Changed in Haskell? | The Haskell Programming Language's blog

The 2025 State of Haskell Survey has provided valuable insights into what the Haskell community would like to see changed in the language and its ecosystem. With 553 responses to the open-ended question about desired changes, the survey reveals both specific technical improvements and broader concerns about the language's complexity and accessibility.

One of the most actionable suggestions that emerged from the survey is the replacement of String with Text as the canonical type for textual data in Haskell's base library. As one respondent explained, "The text library must live from base, because none of the APIs of base can use Text, and when people look at base for examples of well-written Haskell code, they end up using String, which is not the right choice." This has been a persistent source of frustration for both beginners and advanced users, and the topic has been actively discussed in the community, particularly in 2022 on the Discourse forum regarding "Bringing Data.Text into base: What is the next step?"

Onboarding of beginners emerged as another major concern, with many respondents highlighting the need for up-to-date content and a centralized entry point to the language. The Haskell Wiki, while well-referenced by search engines, has seen a steady decrease in contributions. The community is encouraged to apply for accounts and contribute to improving these articles. This ties directly into the broader documentation concerns that were raised, with library authors being encouraged to provide more working examples and documentation that goes beyond simple API references. The community has recognized that documentation contributions work particularly well during community gatherings, where people needing documentation can meet with those best positioned to write it.

The complexity of the Haskell language itself was a recurring theme in the survey responses. Many participants perceive Haskell as too complex, riddled with historical cruft, and lacking consistency in how the language and its libraries have evolved over the decades. Specific suggestions include avoiding partial functions in the Prelude and implementing more sane, safe defaults. There have been requests to stop adding language extensions to GHC or even to redesign existing ones with a more holistic approach. This feedback aligns with answers asking for a new Haskell Language Report that could take advantage of the extensions GHC has introduced over the years.

The state of records in Haskell also drew significant attention, though responses remained somewhat vague. Notable requests include enabling OverloadedRecordDot and NoFieldSelectors by default. This suggests a desire for more ergonomic record handling without necessarily committing to a complete overhaul of the system.

Tooling emerged as a common thread across multiple topics. Compilation times were a major pain point, with the prevalent mood being "Make GHC 10x faster." While these suggestions came from end-users without specific technical advice, particular situations like underpowered laptops were mentioned. The Haskell Language Server received frequent mentions when participants complained about development experience, primarily due to direct interaction with it. Memory usage and reliability of the language server are felt by most people.

Program performance and pervasive laziness anxiety were also recurring themes. Developers expressed difficulties in reasoning about lazy evaluation, with resource blow-ups due to misunderstood runtime behaviors making people anxious about deploying or distributing Haskell software. Actionable advice like eliminating lazy I/O was given, as it's known for tripping people up. Some suggestions are more targeted, such as having data structures strict by default and only explicitly lazy when developers wish so, using the StrictData extension.

Ecosystem consolidation and developer experience were highlighted as areas needing improvement. As Haskell and its ecosystem are more than thirty years old, a certain degree of fragmentation in tooling is normal, but it tends to confuse newcomers who don't wish to navigate the intricacies of technical and political disagreements that produced the existing tooling ecosystem. Survey participants helpfully directed attention to projects like uv for an example of a fully-integrated toolchain (tooling management and project management).

Compilation error messages were called confusing, possibly due to a mismatch between the intended audience of those messages and the actual audience. Error messages may feel more intended for implementers than for end-users. Recent versions of GHC have started directing users to the Haskell error index, suggesting positive developments in the coming years. However, improving error messages for end-users who aren't familiar with implementation details remains important.

Minor but still substantial topics included dependent Haskell, which is viewed as a unified solution that can replace otherwise loosely related language extensions. The community also expressed desires for more community engagement, higher regard for non-technical contributions, and improvements in effect systems. The past few years have seen increased research and development of algebraic effect systems meant to replace the shortcomings of existing Transformers/MTL approaches.

Debugging remains a sore point for participants, though the Haskell Debugger seems to address most pain points. The suggestion of "HasCallStack everywhere" is viewed as a symptom of the perception of existing debugging tools and backtrace mechanisms.

An underlying theme across many answers is the question of "To whom does Haskell cater?" Historically an academic project to study non-strict evaluation and pure functional programming, Haskell has grown to be adopted by software engineers in industry, leading to different ways of learning and socializing. A certain proportion of industrial programmers feel disenfranchised by the academic focus of the ecosystem, especially those without academic backgrounds or formal education.

Some responses were particularly memorable and had to be categorized in special ways. "A whole other language" category included suggestions like swapping the meanings of :: and :, removing laziness, or a total language and tooling cleanup, scorched-earth style. Lean and Idris might be more up the alley of those seeking such radical changes. The "I don't know how, but make it better" category included vague rants and self-admitted impossible ideas like "Replace base," "tooling like TypeScript," and "fix the weird syntax."

The survey results provide valuable insights into the preoccupations of a certain proportion of Haskellers, though it's important to note that surveys are self-selecting tools. We cannot possibly know what exactly the community thinks, only what the subset that answers the survey thinks. The variety of answers, ranging from one word ("base") to several paragraphs that could be the start of a GHC Proposal or a Core Libraries Proposal, demonstrates the depth of engagement within the community.

Anyone can open a GHC Proposal or Core Libraries Proposal, and the community is encouraged to do so. Tooling is a common thread to many topics, from beginner onboarding to consolidation of the developer experience. There is a tension between a fully integrated development ecosystem and having a language with multiple implementations that are free to explore different paths.

Thank you again for participating in this year's survey. Each new edition gives us more data points to measure community trends, and they help various groups craft the best experience for Haskell developers. The insights gathered will be invaluable for guiding the future development of Haskell and its ecosystem.