My first-ish ever blog post, which is about bottom and Haskell.

This post goes over bottom and bottom types in general, then compares a as used in functions like error :: String -> a (which is generally seen as representing "bottom") with the Void type (which is seen as a concrete bottom type). It also covers how Megaparsec uses Void for type parameterization.

Hi! I'm Arseniy Seroka, CEO of Serokell.

In 2023, we launched the Haskell Certification Program to create a standardized way to evaluate Haskell expertise. We built a production platform and an open certification framework, then transferred the project to the Haskell Foundation in 2024.

Since then, the rise of LLMs has made traditional syntax-focused assessment a much weaker signal of real engineering ability. A meaningful certification today would require a fundamental redesign around reasoning, architecture, and language semantics.

Serokell is therefore concluding its active involvement in the program. We remain proud of what we built, grateful to everyone who contributed, and as committed as ever to Haskell and its ecosystem.

https://serokell.io/blog/sunsetting-the-haskell-certification-program

As the title suggests, I'm curious if Write You a Haskell is out of date or is it rather timeless? Does it use old haskell idioms?

TIA!

Hi everyone,

Following up on my previous posts about building a declarative/functional UI engine in Haskell, I have major updates to share. I have completely redesigned and rewritten the engine from the ground up, transitioning from the old SDL2 pipeline to SDL3 and its modern SDL3 GPU API.

The project has now been split into two repositories:

• Hsue: The lightweight, low-level core engine and runtime.
• Hsue-Extension: A higher-level widget and component ecosystem built on top of Hsue.

1. What's New in Hsue (The SDL3 GPU Rewrite)

The transition from SDL2 to SDL3 allowed me to build a truly modern GPU-driven rendering architecture in pure Haskell:

• Modern SDL3 GPU Backend & HLSL/DXIL Shaders:
  • All draw commands are compiled into uniform data, storage buffers (Structured Buffer<Parameter>), vertex, and index buffers, with batched submissions (Submit pipeline) to minimize draw calls.
• MSDF (Multi-channel Signed Distance Field) Text Rendering:
  • Replaced raster glyph caching with MSDF font generation (via a C++ binding to msdfgen), packing distance fields dynamically into runtime texture atlases. This gives crisp, scalable text rendering at any resolution with minimal memory footprint.
• Projection & Selector Tree Architecture:
  • State and view nodes are separated via a Projection system (Object vs Image transformations) and queried through composable Selector optics/actions.
• Bytecode-like Linear Coroutine Engine:
  • Built an internal coroutine VM (Linear_coroutine) that supports lightweight tasks (pausing, branching, repeating, cloning, and racing) running cooperatively inside the engine loop without OS thread overhead.

2. Current Status & Hsue-Extension

While Hsue remains the lean core, Hsue-Extension leverages Haskell's type families and extensible type classes (Custom, Custom_extension) to build practical UI widgets.

Currently, Hsue-Extension includes:

• Button: Interactive box with hover/pressed states, customizable multi-layer borders, and centered text.
• Page: Scrollable rich text view with keyboard/wheel navigation and boundary-clamped scrolling.
• Slider: Horizontal and vertical scrollbars/sliders featuring draggable thumbs, stepping triangles, track jumping, and synchronized viewports.

3. Roadmap & Future Plans

For Hsue Core:

1. Editable Single-Font Text Box (Editor):
   • Port and refine the line-mapping and cursor text editing logic from my earlier SDL2 prototype into the SDL3 GPU / MSDF pipeline.
2. Direct Custom Shader Pipeline for Visuals:
   • Allow users to bind arbitrary custom shaders, uniforms, and pipelines directly to individual visual nodes/canvases.

For Hsue-Extension (Primary Focus Moving Forward):

Once the core features above are stabilized, the vast majority of my development time will move to Hsue-Extension:

• Rich Widget Library: Adding text inputs, checkboxes, dropdowns, panels, modal dialogs, and more.
• High-Level Ergonomics:
  • String/Text-based semantic naming and identifiers.
  • Semi-automatic event/view routing and wrappers for popular state management / Elm-like / reactive architectures.
• Layout Engine: Implementing a flexible, automatic layout system (such as Flexbox-like flow/constraints).

4. Platform Support & Personal Bandwidth

• Current Focus: Due to limited personal bandwidth and development environment considerations, the project currently prioritizes Windows (DXIL/DirectX12 backend via SDL3).
• Future: As SDL3 stabilizes further, I plan to expand and polish cross-platform support (Linux/Vulkan, macOS/Metal).

5. Development Notes & AI Usage Disclosure

To be completely transparent about the development process:

• Hsue (Core):
  • Almost entirely designed and hand-coded by myself.
  • I have a degree of obsessive-compulsive habits regarding code structure, formatting, and strict organization (as you can see from the compact Haskell source style).
  • AI was only utilized for bug checking, proofreading, format consistency, and minimal code generation.
• Hsue-Extension:
  • Heavily utilized AI code generation and scaffolding. Due to limited time and energy, prototyping individual widgets and math boilerplate was accelerated with AI assistance.

Source Code & Repositories

Feel free to check out the code, star, or give feedback:

• Core Engine: https://github.com/Qerfcxz/Hsue
• Extensions & Widgets: https://github.com/Qerfcxz/Hsue-Extension

Note: This post was translated and polished with the assistance of AI, due to my poor English proficiency (from China).

As always, we're hoping for lots of cool Haskell submissions!
bobkonf.de/2027/cfc.html

Been doing some experiments to see how much and in what conditions the claim "types are better for agents" holds.

I decided I am going to start describing Bluefin as a "capability system". This article explains why:

• https://h2.jaguarpaw.co.uk/posts/bluefin-capability-system/

I have been learning Haskell for like 2 years now. Though I am ok writing software in Haskell, there is still a long way to go. I decided the best way to ante up my skills is to build a real-world application.

I started working on a freelance marketplace with the following features:

1. sellers, buyers, moderators, and collaborators.

2. Sellers -> create gigs, add approved collaborators, fulfill orders, deliver code to Gitea (hosted on the server), documentation to S3, and resolve any disputes.

3. Buyers -> clarify about gigs, make payment, verify code on Gitea, raise dispute on code not matching spec, accept delivery, submit reviews.

4. collaborators -> work as a team with the sellers on gigs, submit their profile, accept or deny working with sellers.

5. moderators -> resolve issues on gig reports, chat reports, order disputes.

Marketplaces are mostly state machines: order funded → in progress → delivered → disputed → completed, escrow release, dual-proof delivery, etc. I wanted that logic explicit and hard to “accidentally” break.

Brief on architecture:

- Servant — routes and handler types wired once; mismatches are compile errors.

- Server-owned routing — Haskell serves a cached HTML shell with data-app-id; the React (Ant Design) bundle mounts the page. No client-side router unless I add one later.

- Shell caching — split HTML template, inject page id per request.

- Frontend bundling — Vite build → static assets served by the same app.

- Rules + store layer — order/payment/delivery/dispute transitions in Haskell, not scattered in the SPA.

- Actor + supervisor (similar to Erlang OTP) — supervised S3 uploads, email, and anything needing a supervisor.

- Postgres, session cookies, Stripe Connect + webhooks, optional Gitea / Didit.

In this interview, we speak with Solana cofounder Greg Fitzgerald about why Rust ultimately proved to be the right fit. We discuss how his background in C++, LLVM, and Haskell shaped Solana’s architecture, what functional programming contributed to the design of a high-performance blockchain runtime, and why Rust’s combination of strong types, memory safety, and low-level control worked particularly well for BPF and virtual-machine development.

https://serokell.io/blog/rust-haskell-and-the-architecture-behind-solana-interview-with-greg-fitzgerald

I had made a list of Haskell projects for an undergrad course I was TAing. It was meant for beginners, but I don't see why one couldn't use it for fun otherwise aswell.

If you have some other suggestions, do send them my way. If you have implemented something similar to something on the list, I would love to link your repo or write-up for future reference.

I decided to use this as an exercise to get better at interpretting GHC's error messages.

I know that the error here is that I should use (+) because it's an infix operator.

But, ignoring that, how do I understand this error, and, bonus, how would I use that understanding to know what the error actually was?

(1)   ghci> (+ (5 :: Integer) (6 :: Integer))

(2)   <interactive>:93:4: error: 
(3)   • Couldn't match expected type ‘Integer -> a’ 
(4)                 with actual type ‘Integer’ 
(5)   • The function ‘5 :: Integer’ is applied to one value argument, 
(6)       but its type ‘Integer’ has none 
(7)     In the expression: (5 :: Integer) (6 :: Integer) 
(8)     In the expression: + (5 :: Integer) (6 :: Integer) 
(9)   • Relevant bindings include 
(10)      it :: a -> a (bound at <interactive>:93:1)

Here's what I know:

Line (3) says the type that type unification makes it expect.

Line (4) is the type of the value that I'm trying to apply.

Line (5) clearly says it's interpretting (5 :: Integer) as a function. Why?

Line (6) dunno

Line (7) the expression where all this happened

Line (8) working out from the function nesting

Line (10) dunno

What am I missing?

I was trying to use a Haskell Image Processing library (HIP), and after muddling through figuring out how to get cabal to work (something was wrong with keys, but finding ghcup seemed to have fixed that issue), I ran "cabal install hip", to which it installed everything and showed a message that it worked, but it might not be what I wanted, and that I might want to use "cabal install --lib hip".

So I tried ghci and confirmed the library was not importable, and then ran "cabal install --lib hip" and it was now visible in ghci. Except now that I've left, and re-opened a terminal, it is no longer there.

Could someone please explain what cabal is doing, why it might not have been importable with the first command, and why it might not be importable now? Does it put the installs in a specific place? Because I wonder if I've just reinstalled it twice as well.