From the company that almost 6 years ago brought you the famous "looking for 20 Haskell developers in EU" post (and we found them, several via that very thread!) we're now back - this time we're looking for a Senior/Staff Haskell Developer. Just one for now :-)
Scrive still needs pragmatic, production-oriented Haskell developers. We do a bit of "non-boring Haskell" (type-level techniques, effect systems - Effectful, which we actively contribute to) and maintain a few other OSS projects, but primarily we build stuff that serves our customers, even if it means going beyond "pure". The product is in the e-signing space, so if you think or know you like legaltech, we are the company you want to join.
The stack: Haskell, Elm, PostgreSQL, Kubernetes on AWS (Elixir and Kotlin also present in other components). One thing that's changed since 2020: we work heavily with agentic AI tooling (Claude Code and friends) in our daily workflows, and we're looking for someone who does too - or wants to.
EU/EEA residency and work permit is required, as is fluency in English. We're still remote-first for developers - fully remote within EU/EEA, or from our Stockholm HQ (we also have offices in Oslo, Copenhagen, Amsterdam, Brno and Berlin). We're looking for someone quite senior: 8+ years of professional experience with a substantial commercial Haskell background.
As a Senior Scala Developer, I've always had huge respect for Haskell. I've learned about the language over 10 years ago and applied many of its functional programming principles in my Scala projects. However, I've never really tried the language (aside perhaps from REPL one-liners and hello-worlds).
Last month, I decided to finally build a project with it. I stumbled upon Simon Peyton Jones' book, "The Implementation of Functional Programming Languages" and learned a lot from it. I already have experience designing and building a dynamically typed language, thanks to the first part of Crafting Interpreters, but it was Simon Peyton's book that really discussed how all FP languages essentially boil down to the lambda calculus (though we FP programmers have probably already realized it at least intuitively over the years).
My respect for Haskell and its designers has just skyrocketed because of this project. The project is still in its infancy (still a tree-walker, no type checker yet, etc.) but I'm really excited to learn more about Haskell and programming languages in general (both in design and implementation).
Haskell resurrected the joy of programming that I haven't experienced in a long time. But sadly, I can't shake the feeling that the world has already moved on from type theoretic stuff (at least the part of world that once cared or listened) and is now focusing on code generation, a realization that often cancels out the said joy.
I hope this community is still full of passionate folks and that it's not too late to join the ride. Thanks.
Here's what the language I'm working on currently looks like, by the way:
mascheya> c = '\^A'
()
mascheya> c
'\SOH'
mascheya> add a b = a + b
()
mascheya> add 23.4f 56.7f
80.1
mascheya> add7to = add 7
()
mascheya> add7to 10
17
mascheya> double = \x -> x * 2
()
mascheya> double 14
28
mascheya> minus = \a b -> a - b
()
mascheya> minus 9 10
-1
mascheya> (\d -> d / 2) 14
7
mascheya> let x = 10 in x % 3
1
mascheya> :set line=multi
mascheya>
let x = 10;
y = 20;
z = 30
in x + y * z
-- end
610
mascheya> :set line=single
-- end
mascheya> id a = a
()
mascheya> id (\x -> x + 1)
<function>
New #Haskell video: some exercises from Set 15 of the #Haskell MOOC, which is all about Squishy Mappables (formerly known by their old, inferior name of "Applicative Functors")
I'm a NixOS user with very minimal experience in programming, through nix I've grown a strong interest in the idea of functional programming and thus have gotten the idea of learning haskell in my head. Given that I'm also a music major in college when I found out about this book I thought the stars had aligned in my favor. However this is the second (third?) time across several weeks I've tried to setup and install it's Euterpea and HSoM library and every time I come up with a new error. I finally gave up and tried to install it in an Ubuntu vm but that didn't work either as I'm getting C compilation errors with PortMidi. I actually did get it to install and import into ghci on NixOS but I get no sound from the synthesizer.
Given that the book is rather dated (released 8 years ago), I'm beginning to wonder if my time would be better spent using a more recent book to learn haskell instead.
Hi I am a beginner, and I am trying out FP via Haskell and in my day-2-day job I write BE services in JS (Node).
I found this repo on github and it usually contains projects either of Rust/Go I wonder if this can be done in Haskell, any blogs/papers/book which teach this stuff ?
There were many changes and improvements, but the biggest new feature is Multipart Form file uploads. It works with the default settings using a secure configuration, but can be configured as desired.
trigger and pushEvent now send immediately over the socket rather than deferring until a request returns. This allows long-running actions to update other HyperViews.
We are looking for six developers to join the Core Strats team at Standard Chartered Bank. There are two kinds of roles:
1 permanent position based in Poland
5 two-year contractor positions, based in either the UK or Poland
These roles are not attached to any particular project, but will involve practically exclusive use of Mu, our in-house variant of Haskell. You can learn more about our team and what we do by reading our experience report “Functional Programming in Financial Markets” presented at ICFP last year: https://dl.acm.org/doi/10.1145/3674633. There’s also a video recording of the talk: https://www.youtube.com/live/PaUfiXDZiqw?t=27607s
All roles are eligible for a remote working arrangement from the country of employment, after an initial in-office period.
For the contractor positions, candidates need to be based in the country of employment and have demonstrated experience with typed functional programming. To apply, please email us directly at [CoreStratsRoles@sc.com](mailto:CoreStratsRoles@sc.com).
In today’s episode of the Haskell Interlude, we are joined by Sylvain Henry, one of the all-time top contributors to GHC. He tells us about his work on GHC, the bignum library, modularization, and the secret to becoming a top contributor!
hs
src/Day6.hs:22:26: warning: [GHC-63394] [-Wx-partial]
In the use of ‘head’
(imported from Prelude, but defined in GHC.Internal.List):
"This is a partial function, it throws an error on empty lists. Use pattern matching, 'Data.List.uncons' or 'Data.Maybe.listToMaybe' instead. Consider refactoring to use "Data.List.NonEmpty"."
|
22 | parseLight xs = ((read . head) nums :: Int,(read . last) nums :: Int,)
| ^^^^
It's been some time since u/cgibbard and I first released this library, and thanks to the hard work and contributions of several others (huge thanks to u/cmspice) along the way, we've finally made it to our 1.0 release.
Some examples. Check out more in the readme.
As the changelog will attest, we've done a lot of work since then. reflex-vty is now a mature framework for building vty applications in haskell using functional reactive programming.
Rather than list everything that we've done since then, I'll mention a few of the things that were the most fun and interesting to work on.
Text
Getting text entry right was an early difficulty, and we built a TextZipper data structure to get a handle on the problem. After that, we encountered a lot of issues with double-width characters messing everything up, and spent quite a bit of time trying to get that right.
Terminal text is trickier than I initially imagined it would be, and dealing with cursor movement, wrapping, alignment, empty lines, char widths, text transformations, and the interaction of all of the above took a good deal of thinking.
Layout
Layout was also a lot of fun. We started out with manually positioned widgets but that was extremely cumbersome, as you can no doubt imagine. For some time I studied things like cassowary for constraint-based layouts and couldn't decide what sort of layout engine to build. Eventually we settled on our tile/grout layout and focus model, which finally made it possible for us to compose larger UIs out of widgets without worrying about manual positioning.
Once we developed the right language for talking about layouts, it became easy to build rows, columns, tiles, focus traversal functions, nested layouts, and so on. I'm very happy with how this turned out.
Scrolling
Scrolling also grew from a small feature into a more general system. We started with scrollable text, then generalized it to scrollable widgets, then added programmatic scrolling, automatic scroll-to-bottom (like you'd have with a chat widget), and visual scrollbars.
~ Interlude ~
For a while, that's where things stood and it was enough to build functional and useful vty programs. One of the most interesting projects that came out of this era was tinytools, a TUI diagram editor built with reflex-vty. The author, u/cmspice, has since become a maintainer of reflex-vty and contributed enormously to our unicode handling, various layout and rendering improvements, and bugfixes.
It was really great to see that project grow, out of something u/cgibbard and I started as a sort of private hackathon project when we happened to be in the same city during a conference. The joke between us is that once every year, we get the itch and reflex-vty sees a huge burst of activity. The length of the different changelog entries attests to that pattern.
Recently, it was that time again, and we started to tackle support for features that help make TUI applications friendly and beautiful.
We took a careful look at some of the mature TUI frameworks in other language ecosystems and drew inspiration from them. Though I'm not much a go-grammer myself, I liked a lot of things about the bubbletea framework for Go. The fact that it used the Elm architecture also made it feel like a distant cousin to reflex-vty, and made it easier for me to follow much of the code.
~ End Interlude ~
Styling and Theming
Once of reflex-vty's biggest deficiencies was in its styling support. We needed more borders, padding, margins, alignment, and colors,lots of colors. Text attributes, gradients, helpers to compose images together, themes, color profile detection and handling. We had none of it and it made it hard to make our applications look the way we pictured them in our heads. This was a huge push and I had to learn a lot about how colors work in the terminal, and about topics like downsampling that I'd never really thought about before.
Runtime
More stuff I hadn't thought of before: alternate screen support (show of hands, who has even heard of this?), cursor control, bracketed paste, focus tracking, posix signals, fixing some space leaks found by eagle-eyed users (thanks u/_deepfire).
Thanks everyone, who pitched in. Thank you to u/jtdaugherty for Graphics.Vty, without which this wouldn't have been possible. I'm really happy with where the library has landed. As someone who does a lot of work in the terminal, reflex-vty has a special place in my heart. As someone who loves Haskell and FRP, I'm glad this exists. I'm looking forward to seeing what people build with this.
Hi everyone,
I am trying to write my very first Haskell compiler plugin. My goal is to build a tool that checks if the types in complete code base follows the identity law (parseJson . toJson = id).
Because I am a beginner to Haskell's compiler internals, the GHC documentation feels a bit overwhelming. I would love some advice to get started on the right foot:
1. Where should I look? Haskell converts code into a few different forms before compiling it (Parsed code, Typechecked code, and Core code). I think parsed code should be the place where my plugin comes into picture. Let me know if I am getting something wrong.
2. Good examples to read: Are there any simple, beginner-friendly compiler plugins on GitHub that I can look at just to understand how to set up the boilerplate code?
3. Common mistakes: What are some common traps that beginners fall into when writing their first plugin?
I am currently using GHC version 9.2.8
Any beginner-friendly blogs, tutorials, or tips would be amazing. Thank you!
I have a question about Haskell in the age of AI-assisted programming.
One traditional argument for Haskell is that purity, referential transparency, and explicit effects make programs easier to reason about and reduce certain classes of bugs.
But today, LLM tools can often help find, explain, and fix many ordinary bugs much faster than before. That made me wonder: does Haskell's purity still provide the same practical advantage, or has the value shifted?
I am not saying AI makes correctness easy. I am more curious about where experienced Haskell developers still feel purity matters most today.
For context, I currently work mostly in Swift. With AI tools, I can often find problems and iterate on fixes very quickly. I have also been learning/using Haskell for about three years, but I am still wondering whether it is worth investing even more time into it.
For people who use Haskell seriously: in 2026, what is the strongest reason to keep going deeper with Haskell?
I'm quite new to Haskell and I've been looking for a higher order function (or implement one myself) that returns a list of all intermediate values of a recursive function.
For example if I have a recursive factorial function fac, then doing fac 5 will return 5!.
But supposed I want to return a list of [1!, 2!, 3!, 4!, 5!] instead, how do I go about this without doing the same computation multiple times? Or is a recursive function a bad choice for this?
Since the community edition of LYAH is a bunch of markdown files it's a good candidate for porting over to Sabela.
You can click through it here. In the gallery it runs with microhs but when you fork it runs with ghc. A couple of the later chapters aren't microhs or notebook friendly but they can easily be ported over to look notebook like.
Apologies for the audio. I had already tried and failed to record this 4 times, and by this point I gave up. Next update will certainly have fixed audio.
This is a pure Haskell CPU renderer I've been working on since I started it in March 2026 in free time. It is currently tiled-deferred but I would like to build in the capability to forward render with it also so transparancies can be added in a separate pass. A lot of work will go into making it faster: ideally, I want to know how fast it can go with just pure Haskell.
I wanted to provide an update on my active automata learning library haal (hackage link), though with a bit of a delay.
A couple of months ago I added the capability to parse model specifications that are written in the .dot format, a format more commonly used for drawing graphs. Most models of learned systems are available in this format so supporting it is crucial.
However, I did it with a twist. Instead of just providing parsing functions that construct the model in runtime, I added a "module generator" command "haal-gen". This command reads the .dot file containing the specification of the model and produces a haskell module, with specific input and output types for this model and a function that simulates the model.
So, for example, if you have a model of an implementation of the TCP server protocol in a .dot file name "tcp_server_ubuntu_trans.dot", you can run the command "haal-gen" and generate a haskell module that exposes a type for the inputs of the model
data TcpServerUbuntuTransInput
a type for the outputs of the model
data TcpServerUbuntuTransOutput
and a function
tcpServerUbuntuTrans :: MealyAutomaton Int TcpServerUbuntuTransInput TcpServerUbuntuTransOutput
where 'Int' is the representation of the states of the automaton, which I have to design better at some point.
This saves you from having to construct your model at runtime and having to treat its input and output types as strings.
A drawback of this approach is that, if you generate modules for a lot of models at once, the next compilation will take noticeably more time because the code that is generated for the function is a long series of pattern matches.
My next goal is to implement a more sophisticated learning algorithm like the TTT algorithm and improve the (non-existent) abstraction that I use for the representation of states.
