We’re rebooting dataHaskell! We’ve collected learnings from the previous dataHaskell effort and decided to revive the effort with a simple promise: make doing data science and machine learning in Haskell feel welcoming, practical, and fast. We’ve setup an ambitious roadmap that we are excited to iterate on in the next two years.

This is still a work in progress with many kinks in both our processes and our software but we are committed to delivering on these goals in the medium to long term.

What we’re doing differently

• Single happy path: We’re starting off by building a single, robust happy path that tackles common data science tasks.
• Reducing time-to-first-run: Thoroughly document setup/environment and work with maintainers to fix pain points.
• Better documentation: Produce and encourage thorough documentation using the diataxis framework. Documentation should be runnable so it doesn’t drift from implementation.
• Clearer ownership: Named maintainers per repo, issue triaging, and a clear “how to become a maintainer/contributor” guide per repo. We would like to build continuity into the ecosystem.
• Community: A predictable heartbeat (e.g., monthly community call, fortnightly “help-wanted” sweep, monthly release notes) for collaboration.

Our core values

Our focus begins with people. A community only grows if it’s safe to be curious, to get things wrong, to ship small and often. We’re rebuilding that culture deliberately: clear on-ramps, friendly discussion, and real projects to gather around.

From there, we’re backing the community with an opinionated stack that favors ease of installation and ease of use over endless choice. Rather than present a buffet of options, we’re holding the bar high for a narrow path that “just works.”

Onboarding will be a first-class concern—both for people who want to use the stack and for people who want to build it. Users should be able to get to a running notebook, load a dataset, and try a model in minutes; contributors should find labeled issues, short feedback loops, and maintainers who make time to review and mentor. We’ll favor copy-paste examples over abstract diagrams, concrete error messages over vague advice, and recipes you can run unchanged on day one. If something takes ten steps, our goal will be to reduce it to three, then to one.

As we grow, we’ll keep asking the same practical questions: Where are people getting stuck? What’s the smallest change that removes the most friction? Which capabilities unlock real work next—plotting, faster I/O, GPU ergonomics, better docs, friendlier errors? We’ll publish short roadmaps, but we’ll also let usage guide us; the stack should evolve where the community is actually leaning.

If you’re wondering how to help, the answer is wonderfully ordinary. Start by using the packages and tell us where they hurt. Install the stack, open a notebook, try a tutorial, and file the friction you hit—installation snags, confusing APIs, surprising performance cliffs, places where the docs don’t match reality. That feedback is oxygen. If you like to code, pick up an issue and land a focused PR. If you write well, tighten a README paragraph, add a troubleshooting note, or turn a working example into a short tutorial. Little improvements compound, and the fastest way to make Haskell great for data is to sand one rough edge at a time.

Most of all, come say hello in our Discord. Share what you’re building, ask for a pointer, or offer one to someone else. We’re rebuilding dataHaskell as a place where the path is short, the tools are sharp, and the door is open. With a welcoming community and a small, reliable stack, Haskell can be delightful for data work—and that’s the future we’re leaning into together.