🚀 Introducing `neo`: A CLI Tool for Your NeoHaskell Projects

We're excited to announce the release of neo, the official command-line interface for NeoHaskell — a growing dialect of Haskell focused on clarity, composability, and modern tooling.

This release marks a major milestone: for the first time, you can create, build, and run a NeoHaskell project from the terminal using a single tool.

⚡ What Can neo Do?

The current version of the CLI supports three core commands to help you get started fast:

🆕 neo new -n "my-project"

Generates a new NeoHaskell project scaffold with:

• A MainModule.hs entry point
• A neo.json configuration file
• A clean layout with everything you need to start writing NeoHaskell code

Just run the command and start coding—no boilerplate or manual setup needed.

🔨 neo build

Compiles your project using NeoHaskell’s internal build pipeline.

⚠️ Note: The build process is currently slower than ideal.

We’re aware of the bottlenecks and have improvements scheduled for future sprints.

▶️ neo run

Runs your compiled project. This command wires everything together and launches your NeoHaskell program with zero configuration.

Perfect for quick feedback loops and iterative experimentation.

🧪 Try It Out

You can install neo and create your first project in seconds:

curl --proto '=https' --tlsv1.2 -sSf https://sh.neohaskell.org | bash
neo new -n "my-project"
cd my-project
neo build
neo run

🛤️ What’s Next?

With the foundational CLI in place, the next sprint will focus on:

• 📦 Designing the project structure and conventions for NeoHaskell's built-in event sourcing framework
• 🧱 Scaffolding support for events, commands, and read-models
• ✨ Adding commands like neo generate to create components and wire them into your application automatically

The goal is to make event-driven apps idiomatic and ergonomic in NeoHaskell—without requiring external libraries or complex setups.

🪞 Retrospective on Sprint 1

Well, I’ve completed the first sprint of NeoHaskell. The experience has been pretty good—it gave me a block of time where I could say, “Okay, I commit to these tasks,” and that helped me avoid falling into the endless loop of optimization and perfectionism, which is probably what kills a lot of projects like this.

It’s also helped a lot in starting to treat NeoHaskell as an investment project. Ultimately, it’s something I’d really like to see succeed, and ideally, I’d love for it to become a tool I use to create products—something that allows me to build full-stack apps ten times faster than any tool currently on the market. Of course, it will have trade-offs like any tool—there’s no silver bullet—but a boost in productivity is very likely. This is something I already achieved when I worked with the Booster Framework team, and I think integrating that into a programming language with the vision of NeoHaskell is absolutely possible.

Back to the sprint: things I liked — I enjoyed giving the sprint a theme. The goal of this first sprint was to have an MVP of the NeoHaskell CLI tool. And an MVP is just that—minimum. Like LinkedIn’s former CEO said: if you're proud of what you’ve just launched, then you launched too late. And I’m definitely not proud of the MVP of the NeoHaskell CLI 😅 but hey, there’s now a tool that, despite being slow and not offering the best user experience yet, allows you to compile, run, and create NeoHaskell projects easily.

Also, the installer now supports a one-click install and integrates with Nix. So behind the scenes, there's already quite a bit of machinery in place to make future configuration and extensions easier.

Things that didn’t go as well — I’m not sure if a two-week sprint is the right cadence. Less than that feels too rushed to match the theme, but two weeks might be dragging it a bit too much. Still, I’ll stick with two weeks for now and see how it goes.

For the future, I want to keep the practice of having just a few tasks in each sprint. This time, it coincided with a very intense work period, which drained my energy to contribute as much as I wanted. But thanks to keeping the sprint scope really tight—and keeping the tasks small—I was able to make it satisfying.

For the next sprint, I want to start rethinking the core framework of NeoHaskell. Right now, it’s heavily inspired by Elm, and while that’s fine, I’d like to shift more toward event modeling. That could make it easier to design and architect projects. These two approaches aren’t mutually exclusive, of course, so for Sprint 2, the theme will be to have at least a basic event modeling plan in place.

I’m not totally sure how I’ll break that down into tasks yet, especially in terms of code, but at the very least I’ll work on it and hopefully generate some documentation around it.

To sum up Sprint 1: aside from deprioritizing the REPL task (because I think it's more valuable to focus on solidifying the event modeling / event sourcing foundation for now), I’m happy with the results. Once that base is solid, the CLI structure can be rethought. We might even get to a point where there’s a neodev command to run the project in development mode—which would include executing the main, and potentially having a REPL for exploring and testing functions interactively.

In the future, this could even open the door to more tooling around event sourcing, like a debugger that works like a time machine, or a way to visualize the project architecture.

But for now, there is a working CLI—it’s not perfect, but it works, it installs, and it does what it’s supposed to. For the next sprint, I’ll be doing the same: building something that works as a solid base, this time for the NeoHaskell framework itself.

That’s the update—I hope you're as excited as I am. Let’s keep going and bring the best programming language ever into existence.

Want to help shape the future of NeoHaskell? We’re building it in the open—contributions, feedback, and ideas are all welcome. Jump into the GitHub repo or join our Discord server to connect with the community.