DEV Community: Nick Tchayka

Going Full-Time NeoHaskell

Nick Tchayka — Tue, 04 Nov 2025 10:04:34 +0000

So here's what's been happening lately. After my contract ended with my last client, I decided to take a different path than usual. Instead of immediately jumping into the next opportunity, I'm working on NeoHaskell full-time while living off my savings.

I know that might sound concerning to some, but there's actually a solid plan behind this decision. The goal is straightforward: turn NeoHaskell into something that can sustain itself financially. Not just as a hobby project, but as something I can actually live from.

The approach I'm taking is very production-focused. I'm starting with the core infrastructure that any real application needs - an event store built on PostgreSQL. Nothing experimental or overly clever, just reliable technology that works. After that comes the command handling and read models. These might not be the most exciting features to talk about, but they're what you need to actually ship software.

To help make this sustainable, I've opened several ways to support the project: Open Collective, Ko-fi, GitHub Sponsors, and a few others. Every contribution helps keep this going.

What makes me optimistic about this path is that I already have a prospect client who's committed to using NeoHaskell for their project. This is huge because it means every feature I'm building is being validated against real production needs. Instead of guessing what developers might want, I'm implementing what someone actually needs to ship their product.

This client-first approach is shaping the project in really positive ways. I'm focusing on the leanest possible changes that deliver immediate value. Every addition to the language and ecosystem is driven by actual requirements, not theoretical possibilities. This constraint is exactly what NeoHaskell needs right now.

I'm also offering consulting services around NeoHaskell and event-driven architectures. If you're curious about using NeoHaskell for your project or want help with event sourcing in general, I'd be happy to chat.

The next few months are going to be interesting. Working on NeoHaskell full-time means I can finally give it the attention it deserves. The event store is coming along nicely, and with real production use cases driving development, I'm confident we're building something genuinely useful.

Thanks for following along on this journey. Whether you're contributing code, supporting financially, or just keeping up with the updates, you're helping make this project real.

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

Nick Tchayka — Thu, 27 Mar 2025 20:09:00 +0000

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.

Hypersigilating NeoHaskell and Speedrunning Life

Nick Tchayka — Sun, 02 Mar 2025 12:38:32 +0000

Well, all right. So you might be asking where the hell has been Nick? What the hell has been he doing with NeoHaskell and all that jazz. So basically a lot of stuff was happening in my life.

Some of you might have known that I got married in December. Yay for me. And also throughout that process, I decided to quit my job and basically start rethinking my life. So there was a lot of stuff going on. We prepared a wedding in a month and a half together with my wife. We like to say that it was "Wedding Speedrun Any%," but it was 100% what we really wanted it to be. We had an extremely good time with our closest friends and family and did it as nerdy as we wanted our wedding to be. Basically, we are super happy for that. It was time after being 13 years together.

Now, after that, we also improvised a honeymoon because we hadn't thought about it until two days before the wedding. And we decided to go to Russia. Yes, I know times are weird about that. Some people might like it, some people might not. But to be honest, taking the political views apart, I highlight the fact I don't subscribe to any kind of violence. The country is very beautiful, and especially having relatives there, it was very easy for us to go there and visit. We really, really enjoyed the hospitality of Russian people, taking into account that it was my wife's first time going to that country and my first time going to that country as an adult. So we spent a great time there.

Meanwhile, I was unemployed, doing a lot of stuff. I really appreciated having free time to be able to do things related to the wedding, the honeymoon, and especially taking care of my home. I took the time to set up a proper home office, clean stuff, sort things around, and essentially get back the balance there. I also reconnected with friends, reconnected with video games, which was something that I had abandoned for a long, long time and that I really enjoy, to be honest. I also reconnected with hobbies like music production, just having fun and reconnecting with life.

In February, I was lucky enough to get an offer for a new job, and I accepted. I've been working there for a month already, and it has been a very exciting journey. Of course, it's a new job, new technologies for me, a new business domain, and especially a new kind of workflow—how the teams are organized, how the knowledge is structured, how the codebase is structured, and how a fully product-focused team compares to a services team that I was previously working with. So it has been a lot of learning, of course, a lot of taxing in terms of energy. And yeah, I've been learning for months, and I keep learning.

But of course, I haven't forgotten about my biggest project, which is NeoHaskell. I really plan to keep going on with that. I really want to continue working on it. Some people have doubts about it, and that’s completely fine. I would be in the same place. There's a lot of discontent in the Elm community due to the opacity of the development process there. Thankfully, NeoHaskell is in a very, very early stage, so there’s no one waiting for production fixes or anything. But whatever.

Basically, I was also rethinking a bit about how I was working throughout the project. Initially, I had this plan of drawing everything, planning everything first, and then starting to develop. But again, that wasn’t very realistic because there's a lot of stuff to plan and a lot of stuff to develop. So I ended up diving in and just starting to develop. But again, that becomes another rabbit hole because you end up implementing a lot of stuff that you don’t need immediately.

Given that NeoHaskell is going to have a strong focus on event modeling and event sourcing, I decided that I should probably start planning graphically. For example, the Neo CLI tool will be the first NeoHaskell application. I decided to start with the event model. In fact, you can see here attached the preliminary Neo CLI Event Model. It’s not even finished yet, nor will it ever be, because event models are constantly changing. I want to figure out the best place to put this online so it stays updated.

You’ll see that there’s a lot of stuff missing there—stuff like slices, chapters, etc. And if you’re not familiar with event modeling, it’s a very great concept. I really recommend reading through Understanding Event Sourcing book. Even if you’re not using event sourcing, event modeling is a great design process to help you simplify how you document and design your software. Of course, feel free to leave your opinions here in the comments or in the Discord channel. I’ll be very happy to discuss this.

Back again to the topic, I essentially want to take the time to design the minimal stuff, make it using diagrams and graphical resources, and then map those to actual tasks that can be finished in one day. One day doesn’t mean eight hours because I’m not working on this full-time, but one day means a couple of hours that I have in the evening. This will not only enable me to go faster and provide results for the community, but also I believe that it will allow people to onboard faster. This event modeling tool or design process allows us to go much, much faster in terms of onboarding because all the knowledge is right there.

Writing design documents is hard, but writing diagrams, which are very graphical, is not only easier in my opinion but also much more fun. So basically, I have a branch called develop that has been long-running for a couple of months now. I really want to release the first neo build feature so people can use it, but that’s probably unrealistic. I’ll just end up merging that into the main branch, where the neo build command is basically a Hello World. I think that makes much more sense because then we can keep iterating quickly and providing more stuff there.

Also, you might be wondering, but not everything can be done through an event model. And you’re completely right. There’s a lot of stuff that we still need to model and document. For example, one of the things that I have in mind is to create a diagram, a table, or some graphical resource that maps the collection type, class, or trait (which we don’t have right now) to the different type classes that Haskell has. So we would have this trait called collection that we could use in order to make our code more generic without having to get into concepts like Functor, Foldable, etc., which are very useful on their own but do not give immediate value to newcomers.

So yeah, basically, this is me rambling a little bit about what has been going on, what has been on my mind, and also what I see for the future. I hope this gets you a little bit excited because I really am. I want to keep going forward with the project, and I want to keep hearing from you folks. So thank you for reading this.

That’s all from my side. The wizard has spoken.

NeoHaskell v0.5.0 - HTTP, TOML, Nested Actions Now Executed and Major Refactoring

Nick Tchayka — Mon, 16 Sep 2024 15:55:00 +0000

We are excited to announce the release of NeoHaskell v0.5.0, featuring significant improvements, bug fixes, and new functionalities. This version addresses major issues from previous releases and introduces enhancements that improve the reliability and performance of NeoHaskell applications.

🚀 New Features and Improvements

🛠️ Fixed Execution of Nested Actions

Issue Addressed: Nested actions were not being executed, leading to incomplete workflows and unexpected behavior.
Solution: Refactored the action processing system to correctly handle and execute nested actions.
Impact: Ensures that all intended actions are performed, providing more reliable and predictable application behavior.

🌐 Introduced HTTP Client Support

Capability: Added HTTP client functionalities using the http-conduit library.
Modules Added:
- core/http/Http.hs
- core/http/Http/Client.hs
Features:
- Perform HTTP GET requests with JSON parsing.
- Seamless integration of HTTP requests into NeoHaskell applications.
Note: Currently supports only GET requests.

📄 Transitioned from YAML to TOML for Configuration

Change: Replaced YAML configuration support with TOML.
Reason: TOML offers a simpler syntax and is better suited for configuration needs.
Action Required: Users must migrate their YAML configuration files to TOML format.
Modules Affected:
- Removed: core/yaml/Yaml.hs
- Added: core/toml/Toml.hs (using the toml-parser library)

⚙️ Refactored Core Modules

Standardization and Cleanup:
- Removed custom implementations and redundant GHC extensions.
- Cleaned up imports and exports in core modules for clarity and maintainability.
IO Module Enhancements (core/core/IO.hs):
- Added map and try functions for improved error handling and functional composition.
Result Module Enhancements (core/core/Result.hs):
- Introduced fromEither function for better interoperability with Haskell's Either type.

🚀 Improved Service Layer

Action Processing (core/service/Action.hs):
- Rewrote action processing logic to correctly handle nested actions.
- Adjusted the Action type and related functions to support new data structures.
Event Handling (core/service/Service/EventWorker.hs):
- Enhanced event worker logic to accurately process events derived from actions.
- Ensured proper propagation of events throughout the system.
Runtime State Management (core/service/Service/RuntimeState.hs):
- Refactored runtime state handling to use standard data types.
- Simplified registration of default action handlers and improved extensibility.

🧹 Removed `large-anon` Library and Anonymous Records

Change: Eliminated the large-anon library and the use of anonymous records.
Reason: To simplify the codebase, reduce complexity, and improve performance.
Changes Made:
- Replaced anonymous records with standard Haskell data types using data declarations.
- Removed GHC extensions: OverloadedRecordUpdate, RebindableSyntax, and unnecessary OverloadedRecordDot.
- Updated all modules to use conventional records, enhancing compatibility and maintainability.
Note: This feature might be reintroduced in the future.

📝 Miscellaneous Changes

Updated Cabal Files:
- cli/nhcli.cabal and core/nhcore.cabal updated.
- Removed unused dependencies and GHC extensions.
- Added new dependencies: http-conduit, toml-parser.
Console and Logging Enhancements:
- Improved logging messages for better debugging and visibility.
- Standardized log formats and included more contextual information.
Code Cleanup:
- Removed deprecated code and modules (e.g., core/yaml/Yaml.hs, cli/src/Neo/Transpile.hs).
- Ensured all modules are updated to use new data type definitions.
Removed Modules:
- Deleted content of core/core/Record.hs as it's no longer necessary.
- Removed dependencies on external libraries in core/service/Html.hs, provided placeholders instead.

⚠️ Breaking Changes

Data Types:
- Replaced anonymous records with standard data types.
- Affects the structure of State, Event, Action, and other core components.
GHC Extensions:
- Removed extensions that were previously required for anonymous records.
Configuration Files:
- Users need to migrate their configuration files from YAML to TOML format.
Module Imports:
- Updated module imports and exports.
- User code may require updates to accommodate these changes.

🔧 Action Required for Users

Update Configuration:
- Migrate your YAML configuration files to TOML format to align with the new configuration system.
Code Adjustments:
- Review your code for dependencies on anonymous records and update to use standard data types.
- Check for any GHC extensions that may no longer be necessary or supported.
- Update module imports to match the new module structure.

📣 Conclusion

NeoHaskell v0.5.0 brings important fixes and enhancements that improve the overall stability and functionality of the platform. While some changes are breaking, they pave the way for a more robust and maintainable codebase. We recommend all users upgrade to this version and adjust their code accordingly to benefit from the improvements.

Thank you for your continued support and contributions to NeoHaskell!

NeoHaskell v0.4.0: Update with Concurrency Fixes and Architectural Improvements

Nick Tchayka — Sun, 01 Sep 2024 17:33:00 +0000

After 3 weeks facing a wall of awful, I managed to fix this concurrency bug in the service worker architecture, where even though the user app loop was being executed properly, the exceptions weren't exiting the app. This critical fix, along with several other significant improvements, marks the release of NeoHaskell v0.4.0. Let's dive into the details of what's new and what's been fixed in this major update.

The Concurrency Bug: A Deep Dive

The core of the problem lay in our service worker architecture. While the main application loop was running as expected, any exceptions that occurred weren't properly propagated to cause the application to exit. This led to situations where the app would appear to be running, but was actually in a broken state.

The fix involved several steps:

Implementing a shouldExit flag in the RuntimeState:

   type RuntimeState (event :: Type) =
     Record
       '[ "actionHandlers" := Action.HandlerRegistry,
          "actionsQueue" := Channel (Action event),
          "shouldExit" := Bool
        ]

Adding exception handlers to each worker thread that set this flag:

   let cleanup threadName exception = do
         print [fmt|[init] EXCEPTION: {toText exception}|]
         print [fmt|[init] {threadName} cleanup|]
         print "[init] Cleaning up"
         runtimeState |> RuntimeState.modify (\s -> s {shouldExit = True})

Modifying each worker to check this flag and exit cleanly when set:

   state <- RuntimeState.get runtimeState
   if state.shouldExit
     then do
       print "Exiting due to shouldExit flag"
       IO.exitSuccess
     else do
       -- Continue with normal operation

This change ensures that when an exception occurs in any part of the application, all threads are notified and can shut down gracefully, allowing the application to exit properly.

Major Architectural Improvements

Service Architecture Refactoring

In this major update, we've completely overhauled the Service module, splitting it into smaller, more focused modules:

Service.Core: Core types and interfaces
Service.ActionWorker: Action processing
Service.EventWorker: Event handling and model updates
Service.RenderWorker: View rendering
Service.RuntimeState: Shared runtime state management

This significant refactoring improves code maintainability and makes the system easier to understand and modify, setting a new foundation for future development.

Service Architecture Overview

As part of our architectural improvements, we've refined the core structure of the NeoHaskell Service. To better illustrate these changes, let's examine a high-level diagram of the Service architecture:

ActionsQueue and EventsQueue: These channels facilitate communication between different parts of the system. The ActionsQueue handles incoming actions, while the EventsQueue manages events.
StateRef: This is a concurrent variable that holds the current state of the application model.
Workers:
- ActionWorker: Processes actions from the ActionsQueue and can generate events.
- RenderWorker: Handles rendering the current state of the application.
- EventWorker: Processes events, updates the model, and can generate new actions.
init, view, update (UserApp): Represents the user's application logic, which initializes the State and ActionsQueue, as well as rendering the state, and updating the state based on the events.
Triggers: External sources that can generate events and feed them into the EventsQueue.

The interactions between these components form the core of the NeoHaskell Service:

The UserApp initializes the StateRef and ActionsQueue.
Triggers feed events into the EventsQueue.
The ActionWorker reads from ActionsQueue and writes to EventsQueue.
The EventWorker reads from EventsQueue, updates ModelRef, and can write to ActionsQueue.
The RenderWorker reads from StateRef to render the current state.

This architecture provides a clear separation of concerns, allowing for better management of state, actions, and events in NeoHaskell applications. It forms the foundation for the concurrency improvements and bug fixes implemented in this release.

By clearly defining the roles and interactions of each component, we've created a more robust and maintainable system. This structure allows for easier debugging, better performance, and more predictable behavior in complex applications.

The refinements in this architecture have directly contributed to resolving the concurrency issues mentioned earlier. By clearly defining the flow of data and the responsibilities of each worker, we've minimized the chances of deadlocks and race conditions, resulting in a more stable and reliable system.

Enhanced CLI Argument Parsing

The OptionsParser module has been renamed to Command and substantially expanded with new capabilities:

Support for parsing Path type arguments
Closer integration with the action system for seamless command handling
Improved error handling and user feedback

Other Key Improvements

Terminal Rendering Bug Fix

We resolved a critical issue where the terminal was left in an unusable state after the program exited. This was fixed by properly implementing Vty.shutdown:

(_, vty) <-
  Brick.customMainWithDefaultVty
    (Just eventChannel)
    brickApp
    model
Vty.shutdown vty

Additional Improvements

A new ActionResult type in the Action module for more robust error handling
Introduction of the fmt quasi-quoter for text interpolation
New utility functions added to core modules like Array, Basics, and IO

Conclusion

NeoHaskell v0.4.0 represents a significant step forward in the project's development. The concurrency bug fix addresses a critical issue in the system, while the architectural improvements set the stage for more robust and maintainable code in the future.

These updates provide a stronger foundation for NeoHaskell applications and demonstrate our commitment to improving the language.

As we move forward, we welcome feedback and contributions from the community to help shape the future of NeoHaskell. This major release marks an important milestone, but our work continues as we strive to make NeoHaskell an even more powerful and user-friendly language.

Understanding Triggers in NeoHaskell: A Gateway to Event-Driven Programming

Nick Tchayka — Mon, 05 Aug 2024 13:02:00 +0000

Since the release of NeoHaskell v0.3.0, we've noticed some confusion about what Triggers are and how they can be useful in real-world applications. In this post, we'll dive deeper into the concept of Triggers and explore their potential in various scenarios.

What are Triggers?

At their core, Triggers in NeoHaskell are entry points to your application where external agents can generate events in your service. They act as a bridge between the outside world and your application's event loop.

The Simplest Trigger: Time

Let's start with the simplest example we provided in our release notes:

tickTrigger :: Trigger TickEvent
tickTrigger = Time.triggerEveryMilliseconds 1000 (\_ -> Tick)

This Trigger generates a Tick event in your application every 1000 milliseconds. While simple, it demonstrates the key concept: an external factor (in this case, the passage of time) is causing events to occur in your application.

Let's take a look at hypothetical triggers that could be implemented (they do not exist at the time of writing this, but they will be probably implemented in future versions).

Beyond Time: HTTP Servers

Triggers are far more powerful than just timers. Let's look at how they could be used to create an HTTP server:

postFooTrigger :: Trigger MyEvent
postFooTrigger = HTTP.trigger ANON
  { method = HTTP.POST,
    route = "/foo",
    handler = \_ -> MyEvent
  }

In this example, we're creating a Trigger that listens for POST requests to the "/foo" endpoint. Whenever a request is received, it generates a MyEvent in your application. This is how Triggers facilitate building HTTP servers: they provide a way for incoming HTTP requests to generate events in your application's event loop.

More Real-World Examples

Triggers aren't limited to just time and HTTP. Here are a few more examples to illustrate their versatility:

Chat Bot:

   discordMessageTrigger :: Trigger ChatEvent
   discordMessageTrigger = Discord.onMessage \msg -> 
     NewMessage ANON { author = msg.author, content = msg.content }

This Trigger would generate a NewMessage event every time a message is received in a Discord channel.

File System Watcher:

   fileChangeTrigger :: Trigger FileEvent
   fileChangeTrigger = FileSystem.onChange "/path/to/watch" \change ->
     FileChanged ANON { path = change.path, type = change.type }

This Trigger would generate a FileChanged event whenever files in the specified directory are modified.

Database Listener:

   dbChangeTrigger :: Trigger DBEvent
   dbChangeTrigger = Database.onUpdate "users" \update ->
     UserUpdated ANON { id = update.id, fields = update.changedFields }

This Trigger would generate a UserUpdated event whenever a record in the "users" table is updated.

Why Triggers Matter

Triggers are crucial because they allow your NeoHaskell application to react to the outside world in a structured, functional manner. They provide a clean separation between:

How external events are received (the Trigger)
How those events are represented in your application (the Event)
How your application responds to those events (the Update function)

This separation makes it easier to reason about your application's behavior, test individual components, and modify or extend functionality over time.

Conclusion

Triggers in NeoHaskell are a powerful abstraction that enable truly event-driven programming. Whether you're building a simple CLI tool with a timer, a web server handling HTTP requests, a chat bot responding to messages, or a complex system reacting to database changes and file system events, Triggers provide a consistent, functional approach to handling external inputs.

We're excited to see what the NeoHaskell community builds with Triggers. If you have any questions or want to share what you're working on, join us on Discord or GitHub. Happy coding!

Introducing NeoHaskell v0.3.0: Triggers, Actions, and Services

Nick Tchayka — Sun, 04 Aug 2024 17:37:00 +0000

We're thrilled to announce the release of NeoHaskell v0.3.0! This version brings significant enhancements to our event-driven architecture, making it even more powerful and flexible. The key improvements in this release focus on the introduction of triggers, renaming of core concepts for clarity, and further refinements.

From Commands to Actions: A Clearer Mental Model

In our ongoing effort to make NeoHaskell more intuitive, we've renamed the Command concept to Action. This change better reflects the nature of these operations as side effects that can be tracked and managed within our architecture.

Introducing Triggers: Unlocking a World of Possibilities

The introduction of triggers in v0.3.0 is a game-changer for NeoHaskell applications. Triggers provide a powerful and flexible way to handle asynchronous events and background processes, opening up a vast array of possibilities for your projects.

Let's start with a simple example - a time-based trigger:

tickTrigger =
  Time.triggerEveryMilliseconds 1000 (\_ -> Tick)

This minimal trigger fires a Tick event every 1000 milliseconds. But don't let its simplicity fool you - this is just the tip of the iceberg!

With the trigger system in place, NeoHaskell is now poised to support a wide range of exciting applications:

HTTP Servers: Imagine creating triggers that respond to incoming HTTP requests, allowing you to build full-fledged web applications.
Chat Bots: Whether it's Discord, Telegram, or Slack, you could create triggers that listen for and respond to chat messages in real-time.
IoT Applications: Set up triggers to handle data streams from IoT devices, enabling you to build sophisticated monitoring and control systems.
Database Listeners: Create triggers that react to database changes, perfect for building reactive data processing pipelines.
File System Watchers: Monitor file system events and trigger actions when files are created, modified, or deleted.

The possibilities are virtually endless. Whether you're building a simple CLI tool or a complex distributed system, triggers provide the foundation for handling real-world events in a clean, functional manner.

From Platform to Service: A More Focused Runtime

We've refined our core runtime concept, renaming Platform to Service. This change reflects a more focused approach to managing your application's lifecycle and event handling. Service is a much narrower concept that is much better understood by everyone. And it also opens up the possibility of executing multiple of those in a single application.

Get Involved

We're excited to see what the community builds with NeoHaskell v0.3.0! Here's how you can get started:

Check out our GitHub repository for the latest code
Join our Discord community to discuss ideas and get help

Your feedback and contributions are crucial as we continue to evolve NeoHaskell. Let's work together to create a more accessible and powerful development experience!

Happy coding!

Nick

Announcing NeoHaskell v0.2.0: Bringing Elm-Inspired Architecture to CLI Apps

Nick Tchayka — Sat, 27 Jul 2024 10:38:00 +0000

We're excited to announce the release of NeoHaskell v0.2.0! This version marks a significant milestone in our journey to create a more accessible and powerful Haskell-based language. With this release, we're introducing a basic scaffolding for CLI applications inspired by Elm's architecture, along with substantial enhancements to our core library.

The Elm-Inspired CLI Architecture

One of the most exciting features in v0.2.0 is the introduction of, an Elm-inspired, event sourcing architecture for building CLI applications. This approach brings the clarity and maintainability of Elm's design to the world of command-line tools.

This architecture allows developers to create CLI apps with a clear separation of concerns, making it easier to reason about application state and user interactions.

Let's look at an example of how to build a simple CLI app:

module SimpleTodo (main) where

import Core
import Command qualified
import Platform qualified

type Model =
  Record
    '[ "todos" := Array Text,
       "currentInput" := Text
     ]

data Message
  = AddTodo
  | UpdateInput Text
  | RemoveTodo Int
  | NoOp
  deriving (Show)

init :: (Model, Command Message)
init =
  let initialModel =
        ANON
          { todos = [],
            currentInput = ""
          }
  in (initialModel, Command.none)

update :: Message -> Model -> (Model, Command Message)
update message model =
  case message of
    AddTodo ->
      if Text.isEmpty model.currentInput
        then (model, Command.none)
        else
          ( model
              { todos = Array.push model.currentInput model.todos,
                currentInput = ""
              },
            Command.none
          )
    UpdateInput newInput ->
      (model {currentInput = newInput}, Command.none)
    RemoveTodo index ->
      ( model {todos = Array.removeAt index model.todos},
        Command.none
      )
    NoOp ->
      (model, Command.none)

view :: Model -> Text
view model = do
  let todoList = Text.joinWith "\n" model.todos
  let header = "Todo List:\n"
  let footer = "\nCurrent input: " ++ model.currentInput
  header ++ todoList ++ footer

main :: IO ()
main = Platform.init (ANON {init = init, view = view, update = update})

This example demonstrates the key components of the Elm-inspired architecture:

Model: Represents the application state
Message: Defines the possible events in the application
init: Sets up the initial model and commands
update: Handles state transitions based on messages
view: Renders the current state as text
main: Initializes the application using the Platform module

Expanded Core Library

We've significantly enhanced our core library to provide more powerful tools for NeoHaskell developers:

New concurrency primitives: Channel, Var, and ConcurrentVar
AsyncIO module for handling asynchronous operations
Extended Array module with useful functions like flatMap and forEach
Version module for parsing and working with semantic versions
The Unknown type for handling dynamic typing scenarios
A Record module for working with extensible records
New Json and Yaml modules for data serialization
An OptionsParser module to simplify CLI argument parsing
A Console module with built-in debugging capabilities

Trait System Enhancements

We've reorganized and expanded our trait system to provide a more cohesive and powerful set of abstractions:

Improved Appendable, Applicable, and Combinable traits
A new ToText trait for consistent string conversion across types

Get Involved

We're excited to see what the community builds with NeoHaskell v0.2.0! Here's how you can get started:

Check out our GitHub repository for the latest code
Join our Discord community to discuss ideas and get help
Try building a small CLI app and share your experience

Your feedback and contributions are crucial as we continue to evolve NeoHaskell. Let's work together to create a more accessible and powerful development experience!

Happy coding!

Nick

DevLog 00002 - A main loop working

Nick Tchayka — Wed, 24 Jul 2024 09:20:00 +0000

This week I kept working on having a working Elm-style event-sourcing application main loop in NeoHaskell, and I managed it!

What does it look like to use this right now? Well, more or less like the following. Let’s say we want to write an app that reads a file and exits. Here’s an extremely contrived example:

type Model = Record
  '[ "content" := Text
   ]

initialModel :: Model
initialModel = ANON { content = "" }

data Message
  = ContentRetrieved Text
  | FailedToRead

init :: (Model, Command Message)
init = 
  ( initialModel, 
    File.read ANON
      { path = [path|test.txt|],
        onSuccess = ContentRetrieved,
        onFailure = \_ -> FailedToRead
      }
  )

update :: Model -> Message -> (Model, Command Message)
update model message =
  case message of

    ContentRetrieved text -> 
      (ANON { content = text }, Command.none)

    FailedToRead ->
      (ANON { content = "ERROR"}, Command.none)

view :: Model -> Html
view model =
  [html|
    <div>{model.content}</div>
  |]

main = Platform.init ANON
  { init = init,
    view = view,
    update = update
  }

Don’t get too clinged to the syntax, as it will change in the future. I’m aware that it is not pretty 😄

If you know a bit of Elm, you might get it straight away, but if you don’t you probably are wondering how all of this works. Either way, you might be thinking that this is overkill for just reading a file and printing it, and you are right!

If you still have no idea what is happening here, don’t worry, documentation will be on its way once we finalize this first iteration, but to give you a quick hint: This is setting up a loop in the app where the update function gets executed each time an event gets registered in the app, in this case only once when the file gets read (or not). Because no more events happen, the application will end.

The view function is constantly rendering the model (at 60fps approximately).

Commands, update, and view, all run on different threads, ensuring that your app doesn’t choke on any of those.

Next step is to implement subscriptions, to allow doing much more fun stuff, like listening for interactions in the view, or listening for events from external places (like workers written in other programming languages like Python).

On top of that, tracing functions like print, or trace, are being prepared so they print to a separate thread and output too, which will end up in OpenTelemetry.

Either way, once I got the minimum things implemented for writing a simple build command I’ll merge this and probably work on a distribution script for everyone to try this :)

As usual, you’re invited to Discord and GitHub :D

DevLog 00001 - Command Line Updates

Nick Tchayka — Wed, 17 Jul 2024 11:17:00 +0000

It was a long time since I wrote something decent about NeoHaskell, and my plan was to build openly, so I might start writing devlogs more frequently to publish progress and be able to receive feedback. Many people have sent suggestions about the project and I’m very grateful about them. Also, I think it is cool to have some logs to see how the stuff progresses. It’s easy to dismiss work when one doesn’t write about it.

Lately I’ve been pushing NeoHaskell to get the minimal necessary functionality to be able to write a command line tool for interacting with NeoHaskell projects. This led me to implement multiple micro features in the project, but also it started shaping some interesting modules in the core library.

Perhaps one of the greatest finds for the core library was the awesome library opt-env-conf by NorfairKing on GitHub. What looks on the surface as just another command line argument parsing library, is actually a masterpiece in developer experience design IMO. This library not only allows you to define parsers for your command line program arguments, but also define requirements in terms of environment variables and configuration files. On top of that, it also lets you generate manpages, and autocompletions for your typical shells like Bash, ZSH, Fish, and others.

This library alings very well with the NeoHaskell philosophy of “let the tool do as much as possible, freeing the user of repetitive tasks”. I’ve validated the existence of environment variables countless times in many languages and with many different tools in techniques. It is very refreshing to be able to have a library that has this in mind already, and that’s why I’ve chosen it as the underlying technology of the OptionsParser module in the NeoHaskell core library (name probably will change).

One of the main patterns in NeoHaskell is the Parse, don’t validate philosophy. But NeoHaskell tries to take it even further, by allowing the developer to write parsing code once.

How? Right now it is not fully decided yet, since we have only one parsing module (OptionsParser), but the idea is that you write parsing code once with the parser of your choice (e.g. OptionsParser), and then, if needed, you could switch into a different one (e.g. JSON) with minimal code changes, allowing your app code to evolve slowly into different implementations and platorms.

Perhaps you start writing a CLI app that’s easy to test, but then you decide that it should be an HTTP server, after a while you decide that it could be a mobile app. Those switches shouldn’t be a whole rewrite of the app, and the parsing code for the types that make the boundaries of your application should stay the same, or at least as similar as possible to the previous iteration.

The OptionsParser module implements a thin layer over opt-env-conf to start defining this kind of API, where one can parse different fields by providing a configuration in a record.

Records

Another great find that goes straight into the style of NeoHaskell is large-anon. A Library that allows working with records in a very flexible way.

Of course, Haskell does have records through the usage of data, but those aren’t expandable, nor we can match structurally in type signatures easily. And of course, we cannot just make a record on the fly and pass it to a function.

large-anon provides fixes to all these problems, and also provides a cool DSL that allows you to write code to build records in an imperative way. Also, they implement JSON serialization out of the box, so you don’t have to write any code to enable it for the records you write.

In Haskell, these constructs aren’t first class, so in future versions of NeoHaskell, custom syntax will be introduced to work easily with records.

Commands: Side effects and interop

By the time I’m writing this, I’m in the middle of implementing commands and command handling.

Commands in NeoHaskell are very similar to Cmds in Elm. It is a value that, if picked by the NeoHaskell runtime, it will execute some kind of side effect.

There’s an interesting twist in NeoHaskell commands: The command definition and the handling is completely decoupled.

In fact, not only the handling is done in a separate thread, but you could implement handlers in any language. Yes, you read that right.

Of course, right now this would be pretty rudimentary, but over the versions I hope that the API stabilizes and one could have a very lightweight library for different languages to implement these command handlers in a very easy way that’s integrated with the rest of the codebase.

On top of that, commands can be declared idempotent, this means that we say that the command can be repeated without additional effects happening. Think of when you call an elevator and you keep pushing the button, no additional effects happen, the elevator keeps coming.

This is useful for when the time travelling debugger gets implemented. The idea is that you should be able to debug your app by going forward and backward through the execution of the code.

Event Sourcing and the Elm architecture

The time travelling thingy would be possible thanks to the fact that the main architecture for NeoHaskell apps is the Elm architecture, which essentially is event sourcing

If you’re not familiar with either one, think of your bank account. When you go into the ledger of it, you can see the withdrawals and deposits. And thanks to those, you can calculate the balance at any time by looking at those.

That’s how event sourcing works essentially, you store events and you calculate the state of the app out of them.

What next?

Once I finish implementing the necessary things to have a hello world app for the terminal using these patterns, I’ll probably start to work on a build command in the neo CLI tool that grabs project.yaml and builds the project from there.

I’ve got lots of ideas to come for that, like a nice terminal UI based on minttea by leostera. Also, implicit imports that are configurable, so you don’t have to import any module if you already have it in your deps, and start implementing custom syntax.

I’m pretty excited about the project, it’s addictive to code on this codebase heh.

As always, I invite you to the Discord server to have a chat, and of course to the GitHub repo to contribute if that’s your thing. See you around!

Happy Birthday Me, Happy Birthday NeoHaskell

Nick Tchayka — Sun, 26 May 2024 22:09:00 +0000

Today is a special day for me—it's my birthday and also the release of the first version of NeoHaskell! 🎉 It's exciting to see it being born into the aethereal currents of the internet 30 years after my own birth.

On a personal note, I'm feeling much better since my last post. I've been focusing on my well-being, remodeling my apartment, and really listening to what my body needs. This reboot of NeoHaskell aligns perfectly with my renewed energy and excitement for ongoing development.

First Version Highlights

This first version comes with a forked version of nri-prelude, an excellent library by NoRedInk, designed with Elm's philosophy in mind and mimicking the Elm core libraries. NeoHaskell takes this as an inspiring starting point to build upon, providing a solid foundation for future development.

What's Inside the Core Library

Accumulator: A DSL to gather values into an accumulable type.
Array: Fast immutable arrays.
Basics: Fundamental operations and types.
Char: Character operations with ASCII and Unicode support.
Console and File: Basic IO operations.
LinkedList: Comprehensive list operations.
Map: Builder API for maps.
Maybe: Handling optional values.
Text: Text operations including substring handling and formatting.
Traits: Traits for appendable, default, mappable, and thenable types.

These changes aim to create a well-structured and documented codebase, making it easier for others to contribute and ensuring the project’s scalability.

Getting Started

There aren't any detailed guides or tutorials yet, but you can clone the repository at NeoHaskell Starter to start playing with the new version. For any help or instructions, join us on Discord where the community is ready to support you.

Thanks for being a part of this journey. Let's make great things happen with NeoHaskell!

Introducing NeoHaskell: A beacon of joy in a greyed tech world

Nick Tchayka — Sun, 24 Sep 2023 15:02:07 +0000

Today, I'm proud to announce a (free and open-source) project that I've been working on for many years:

NeoHaskell, a dialect of Haskell that prioritizes newcomer-friendliness and productivity.

I embarked on the NeoHaskell project fueled by a diverse array of motivations. I see Haskell as a supremely potent language, leading the frontier of software development due to its inventive and meticulously crafted nature. However, its potential seems overshadowed by intricate details and a community primarily focused on resolving theoretical academic and mathematical challenges, often overlooking pragmatic solutions, which can be overwhelming for newcomers. Based on my experience with incorporating Haskell into production for two years and the subsequent transition to TypeScript due to escalating complexity, after innumerable conversations with my colleagues at The Agile Monkeys, a critical need for a language that could refine software development while preserving the groundbreaking aspects of Haskell was recognized. This realization, coupled with the challenges encountered in the software development sector, inspired the creation of NeoHaskell. Through this initiative, I aspire to develop an optimal programming language and ecosystem that eradicates accidental complexity, either in mental form, or in code form.

This is a language for those who have just too many things in their head and they want to release their ideas, but don't have the time to commit daily to maintain the required context of their projects in their heads. For those who want to play and have fun while producing awesome software, regardless of their experience, background, or interests. And for those teams that, inevitably, are high-rotational (either internally in the company, or externally) but want to be productive and happy while performing their craft.

A language? A dialect? What do you mean?

Depending on who you ask, a programming language can be different things. If you ask the Haskell community, many will tell you that the language is the Haskell specification, and that what currently is being used is not Haskell itself, but an extension of Haskell that is supported by the GHC compiler. Similar to the C language, a programming language would be a specification.

Other people might tell you that a programming language is the result of the supported features of its compiler, like Rust, which keeps evolving with time.

I personally think that a programming language is the result of the agreement of its community on tools, libraries, patterns and practices. I hear folks saying "he didn't learn Python, he is programming in Java in Python", which is the affirmation of this.

NeoHaskell exploits this philosophy to establish a parallel universe in the Haskell ecosystem, piggybacking the extremely good tooling and libraries that are already there, and were there for a long time. It establishes completely different patterns, practices, naming, and even approaches to code that would be considered heretic in Haskell.

The solution is not having more hands implementing more features, the solution is to stop. And prioritize as if this was a product.

This is not a priority for the Haskell community, and that's the point:

NeoHaskell is not Haskell, it's a parallel universe built on top of it.

What's the goal?

NeoHaskell’s core mission is to provide a seamless, productive ecosystem for joyful software development. It’s designed to guide developers toward faster, more reliable releases, through a concentrated effort to alleviate cognitive load, by removing unnecessary complexity and decision making.

We welcome developers from diverse backgrounds, including backend and frontend development, data analysis, mobile development, game development, and whatever you can image. While simplification of the development process is a priority, NeoHaskell also emphasizes the importance of improving developer satisfaction by incorporating structured architectures to reduce decision making even more.

NeoHaskell's vision is to render the development process more user-friendly and enjoyable, enabling users to realize their ideas effortlessly and efficiently. It wants to transform the development experience, making it feel more like “play” rather than “work.”

Why not just documenting Haskell?

If you think in a programming language as the subconscious agreement of its community, the key part is the way of working and approaching programming as a group. In the same way that the Java community is used to work in a way by defining factories, beans, etc… The Haskell community is used to work in their own way too. It is not wrong, or incorrect, they have their own goals.

The issue is, that documenting technology is easy, changing the minds of an entire community is not.

I'm a single person trying to fix the world. I have limited time and energy, and I don't want to be changing the views of anyone. I'm doing this in my free time, time that I dedicate to be more happy. Convincing people doesn't make me happy.

I'm building a wagon that is open for everyone who wants to hop on and support it, but I don't want to deal with people that don't.

I want to establish a new concept so it is easier for newcomers to find resources and get up and running in the most effective way possible, all while feeling unstoppable because they're using a tool that they love.

In response to any skepticism from the Haskell community, I understand the seen sufficiency of Haskell in its present state given their context and experience. Most of them are very smart people, and great professionals, and they are completely right to think in that way.

However, when considering individuals with diverse approaches to software development, like those viewing programming languages as tools, or those valuing release speed over perfection, including early-career developers with abundant creative ideas, the priorities noticeably shift.

NeoHaskell is focused on enabling swift and assured releases, valuing user-friendliness and practicality over aspects like precision, code accuracy, and complex type-level code for the sake of perfection. The project recognizes that developers have varied needs, and it commits to catering to those prioritizing efficiency and feasibility in bringing their visions to life.

What are you trying to solve exactly?

There are too many entry points to a simple task as running your code, such as plain GHC, Cabal, Stack, Nix, etc., each presenting its learning curve and absence of a recognized superior option. The environment is further compounded by multiple language extensions and different frameworks handling side effects. These, combined with the daunting mathematical concepts in the language, often discourage newcomers.

Not even mentioning even more niche workflows like mobile apps, web apps, and even game development, that are there, but are hidden deep down under layers of accidental complexity.

NeoHaskell counters these challenges by introducing a unified CLI tool that simplifies everything, from installing the required compiler to managing packages and running tests. It streamlines all the different workflows through official templates, so one can get started right away with the task that they want to do.

We aim to support newcomers by providing analogies to other languages and featuring these in the documentation to facilitate comprehensive learning, while renaming or discarding terms that would be unnecessarily complex for newcomers.

How are you trying to solve it?

NeoHaskell’s development is centered around the principle of catering to its community, the NeoHaskell community, avoiding the trap of chasing unrealistic perfection and ending up with an unused product after years of development.

The main goal is to create many different pieces:

A remarkable standard library
An integrated CLI tool with precise error messages
Templates with planned architectures
Documentation with a set of recipes
Mobile app packaging
Python interoperability
And many more

These objectives, though ambitious, are attainable by delivering small increments and focusing on fostering one essential element: developer joy.

Rather than promoting the creation of new architectures and the innovative use of advanced features, NeoHaskell favors well-established patterns in the software industry and embraces functional programming where appropriate, allowing for imperative code where it’s more suitable. Comprehensive documentation, a supportive Discord community, and a philosophy of "if it takes more than 15 mins to figure out, it is a bug" are the key points to ensure the success and happiness of its users.

One of the key ideas of NeoHaskell is to reuse as much technology as possible, while staying in the realm of NeoHaskell. This approach opens up many paths, and leads you very far. Our goal is to be happy while coding what makes our project different, not all the bullshit that just gets in the way. If your goal is to make a todo-list mobile application in the most joyful way, using NeoHaskell, you shouldn't think at all in how the rendering of the view is actually implemented. Even if the mobile app is a React Native renderer of HyperView XML views that are retrieved from a 100% NeoHaskell backend, as shown in this tweet:

// Detect dark theme var iframe = document.getElementById('tweet-1700859705021571543-637'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1700859705021571543&theme=dark" }

When you approach development like this, by doing concessions, instead of closing doors, you open up the door for innovation and improvement, while maintaining a healthy and productive ecosystem. The other way around, you end up with a wasteland filled of gardeners ensuring that someday, the plants will grow exactly in the perfect way that they want.

How does it piggy-back the Haskell ecosystem?

NeoHaskell preserves 100% compatibility with Haskell, seamlessly integrating existing packages and tools designed for Haskell. However, its goal is not to be backward compatible. It will refine several elements from the Haskell standard library, with functions being renamed, certain operators being concealed and new ones introduced, and type classes being restructured to ensure their practical applicability, if they are applicable.

NeoHaskell will actively utilize compiler plugins to modify the compiler’s behavior to align more with newcomer friendly messages and features. It will maximize the potential of existing libraries, sometimes through encapsulation or re-exportation, as well as the usage of all the plethora of great CLI tooling that exists for Haskell.

How will be the design and priorization process?

I believe that in order for a product to be successful, the design process must be centralized in a single person. This person must listen to the users, the other designers, and in general must have an open mind to always cherry-pick all possible ideas in order to improve the product. I don't believe that a product should be guided by democracy, and neither it should implement all suggestions by every user. In other words, I'll be the one in charge of generating and listening to discussions, and prioritizing the features of the project.

I understand that this comes with some risk, but at the same time I believe that all programming tools like Python and Ruby that are very loved by their communities are like that because of the BDFL model.

NeoHaskell's development will be open and transparent, marked by continuous sharing of progress and regular updates. My biggest priority is to maintain the community informed and aware of my vision, not getting into some kind of spiritual retreat to code while everyone thinks that the project has stalled and I have disappeared.

Anyone interested can contribute by participating in discussions on Discord and GitHub. Contributions go beyond code, the most important part is the design process, and that can only be achieved through communication between the members of the community.

I want to contribute, where is the code?

If you've read "the project that I've been working on for many years" as "the project that I've been coding for many years", I'm sorry to disappoint you, that is not the case.

I'm glad that it isn't, because that would have been a complete mistake. Design is a thinking process, is a communication process that goes back and forth. It is about talking to people, listening to every conversation with an open mind. Getting into tasks that you don't like and doing them for the sake of understanding what's going on, what are the users doing, and what is this thing that could improve their lives.

I didn't code NeoHaskell, instead I wrote TypeScript, both for backend, frontend, CLI tools, infra-as-code, and many more things. I worked with enterprise clients whose teams are so big and the team member rotation is so high, that every little code pattern had to be stitched in the exact same way so there were no surprises when team members rotated. I coded plain Java, as well as Python, in the most boring and bland way possible. All of that, taking notes and gathering insights for NeoHaskell. That is the real work. Getting all these puzzle pieces that are spinning in a tornado around you, picking them up, while attempting to stay on the ground and assembling the puzzle.

There's this thing that people call "Haskell curse", which is the feeling of disgust for using other, inferior, technologies that aren't Haskell.

NeoHaskell lifts the curse. Every interaction with technology and users from other ecosystems becomes a blessing, and an opportunity to understand what makes us happy as software craftspeople. Every frustration becomes a leverage point to create the most awesome language, ecosystem, and community ever in the world. So, check out the website, join the Discord, and hop into the project's GitHub, this is not possible without you (literally).

Afterword

Writing this post was not easy at all. I'm very happy that this project finally sees the light, because I truly believe since the day I discovered Haskell in that old dusty book in my faculty's library, that it has the power to be the leading language in software industry. You cannot imagine how many different attempts that I've tried, how many prototypes I actually wrote, and how many conversations I had with developers who thought that Haskell is just hipster bullshit that is not useful at all.

If you've read this far, let me thank you from the deepest part of my heart, even if you don't believe in this project, or you're not interested, and if you are, have this huge virtual hug and let's chat! I'm eager to talk with people that are interested in this idea.

NeoHaskell may evolve as a specialized community or may blossom into something more extensive and mainstream.

My hopes are humble: for it to serve as an invaluable resource enabling the community to experience continual satisfaction, and for it to encourage the Haskell community to emphasize practicality and inclusivity.

Thank you, really,
NickSeagull

DEV Community: Nick Tchayka

Going Full-Time NeoHaskell

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

⚡ What Can neo Do?

🆕 neo new -n "my-project"

🔨 neo build

▶️ neo run

🧪 Try It Out

🛤️ What’s Next?

🪞 Retrospective on Sprint 1

Hypersigilating NeoHaskell and Speedrunning Life

NeoHaskell v0.5.0 - HTTP, TOML, Nested Actions Now Executed and Major Refactoring

🚀 New Features and Improvements

🛠️ Fixed Execution of Nested Actions

🌐 Introduced HTTP Client Support

📄 Transitioned from YAML to TOML for Configuration

⚙️ Refactored Core Modules

🚀 Improved Service Layer

🧹 Removed large-anon Library and Anonymous Records

📝 Miscellaneous Changes

⚠️ Breaking Changes

🔧 Action Required for Users

📣 Conclusion

NeoHaskell v0.4.0: Update with Concurrency Fixes and Architectural Improvements

The Concurrency Bug: A Deep Dive

Major Architectural Improvements

Service Architecture Refactoring

Service Architecture Overview

Enhanced CLI Argument Parsing

Other Key Improvements

Terminal Rendering Bug Fix

Additional Improvements

Conclusion

Understanding Triggers in NeoHaskell: A Gateway to Event-Driven Programming

What are Triggers?

The Simplest Trigger: Time

Beyond Time: HTTP Servers

More Real-World Examples

Why Triggers Matter

Conclusion

Introducing NeoHaskell v0.3.0: Triggers, Actions, and Services

From Commands to Actions: A Clearer Mental Model

Introducing Triggers: Unlocking a World of Possibilities

From Platform to Service: A More Focused Runtime

Get Involved

Announcing NeoHaskell v0.2.0: Bringing Elm-Inspired Architecture to CLI Apps

The Elm-Inspired CLI Architecture

Expanded Core Library

Trait System Enhancements

Get Involved

DevLog 00002 - A main loop working

DevLog 00001 - Command Line Updates

Records

Commands: Side effects and interop

Event Sourcing and the Elm architecture

What next?

Happy Birthday Me, Happy Birthday NeoHaskell

First Version Highlights

What's Inside the Core Library

Getting Started

Introducing NeoHaskell: A beacon of joy in a greyed tech world

A language? A dialect? What do you mean?

What's the goal?

Why not just documenting Haskell?

What are you trying to solve exactly?

How are you trying to solve it?

How does it piggy-back the Haskell ecosystem?

How will be the design and priorization process?

I want to contribute, where is the code?

Afterword

⚡ What Can `neo` Do?

🆕 `neo new -n "my-project"`

🔨 `neo build`

▶️ `neo run`

🧹 Removed `large-anon` Library and Anonymous Records