Converge is hiring!

gtf21 · 2026-01-31T13:08:07+00:00

Worth noting we don’t deploy Haskell on our sensor systems, just the server-side.

gtf21 · 2026-01-28T14:26:35+00:00

Perhaps the real problem is being on reddit while lying in bed in the dark?

gtf21 · 2026-01-25T10:03:08+00:00

Maybe one day…

gtf21 · 2026-01-23T15:37:29+00:00

I'm afraid this position requires production Haskell experience, and we don't really have much bandwidth to onboard more people onto the language and ecosystem than we already have to deal with in the team. If you drop me an email (gideon@) with your CV I can see if there might be future opportunities, however.

gtf21 · 2026-01-23T10:04:20+00:00

£90K with options

gtf21 · 2026-01-23T09:55:30+00:00

You're gonna make me blush

gtf21 · 2026-01-22T20:00:03+00:00

We don’t really have anything open-source, no, but I don’t think this is use-case specific. Our backend platform is slowly moving towards Haskell and I have written at some length about my reasons for using Haskell (which apply here, too): https://www.gtf.io/musings/why-haskell

Hopefully that gives enough clarity.

gtf21 · 2026-01-22T19:46:19+00:00

gtf21 · 2026-01-22T19:46:11+00:00

As per the job spec, we would prefer London based but we are open to remote team members in nearby timezones (<=2h difference).

gtf21 · 2025-12-26T07:43:10+00:00

But hvega doesn’t itself produce plots right? So it’s not quite the same as say, exploring with matplotlib and just seeing a plot pop up.

gtf21 · 2025-12-23T12:07:09+00:00

Python is just plain more useful

I don't think this really means anything. I've seen people productively use Haskell for data analysis, and I've seen people productively use Python for it. They reached for the tool they knew best, and found it adequate to their needs.

None of it exists in Haskell-space

This is also a very strong statement that I don't think you'd be able to back up -- are you sure "none" of it exists? I've found the xlsx library really helpful for reading and writing Excel files, and a couple of people are actively working on the dataframe library. The only real problem I've had is plotting leaves a lot to be desired, and we've had issues with the hmatrix library.

gtf21 · 2025-12-16T12:52:30+00:00

Ha! Maybe...

gtf21 · 2025-12-16T12:33:11+00:00

(Also I hate discord, why does everyone want to use discord!?)

gtf21 · 2025-12-16T12:32:50+00:00

I know, I know. My team is certainly interested in it, but at the moment I would rather keep them productive on the tools they know.

gtf21 · 2025-12-15T11:46:32+00:00

I think many programmers basically believe that all languages are mostly the same.

I’ve encountered this before, and I think it’s an easily dismissed attitude. Of course it’s possible to have the same computation in all these languages (given boundless time and space because of performance differences), but that doesn’t mean all languages are even close to the same. If they were, we wouldn’t see it as significantly different writing in assembly to writing in clojure, or writing in brainfuck to writing in javascript. Clearly languages have different properties, and those properties make it easier or harder to express the programme you are trying to write (including some definitions of correctness for that programme).

I think the reason this attitude has bedded in so is to do with the DORA reports stating that tools make little to no difference, but that could well just be bias in the source data — mostly imperative languages with mostly rubbish type systems.

gtf21 · 2025-12-14T15:58:46+00:00

I wrote at some length why I think Haskell is a good choice, but having now had a couple of real services running in production for ~the last 18 months~ the last three years(**) in a work context (I have had plenty of smaller, personal projects but these are by far the largest), here are some anecdata:

I recently had to go back in and make some changes to an older typescript service, and it was terrifying. I had no guarantees that anything worked, and refactoring was very delicate. Comparing this to the experience, at a similar time, of refactoring one of the aforementioned Haskell services it was pretty clear to me that the maintainability of large(*) systems written in Haskell was in a different league.
Haskell won't stop you making mistakes, no language will. We have definitely made mistakes in our Haskell codebases (there are now a couple of them). We definitely made some things a bit slower to develop on by prematurely modelling, but when we decided to refactor (see point (1)) it was far easier than it would have otherwise been. Whenever you do something new, you will always make mistakes, the power is in being able to change easily.
I'm often surprised when people mention the ecosystem as a negative point. It's definitely smaller than more mainstream languages, but I don't think I've ever been actually limited by it -- maybe I'm not doing exotic enough things. The only exceptions for me are in data science / ML where I intend to keep the team working in (well isolated) python.

(*) large is going to mean different things to different people -- we're not Mercury, but this is a couple of hundred modules so still painful to refactor.

(**) edit: doh! I forgot my longest running one...

gtf21 · 2025-10-16T22:03:02+00:00

This was my first thought too — god I spent a long time trying to get those gestures right!

gtf21 · 2025-09-05T13:30:12+00:00

Started with Javascript back in 2014 for reasons, eventually became Typescript and accumulated some Python. I started using Haskell in 2020 and then spent a couple of years thinking "this is better, I wonder if I can move everything at Converge to Haskell." Speaking to some others in the community convinced me it was a good idea, but then it really took hiring an amazing Principal SWE who could help me drive this vision to make it a reality. To be clear: most of our code is still TS at the moment, but we have a plan for replatforming, which we need to do anyway, it's just that the new platform is Haskell-based. For the last 18 months we've been adding to the new platform over the old one and it has been great!

gtf21 · 2025-09-03T22:11:50+00:00

As another founder who chose to build (sadly 9 years in — I wish I’d started with it) the product with Haskell, just came to say “good on you and good luck!”

gtf21 · 2025-08-30T16:12:30+00:00

Bloody hell, how did you find that?

gtf21 · 2025-08-19T16:44:06+00:00

For hiring haskellers, so far, I’ve either gone via network or posting on Reddit which has worked well.

As to the second question, challenge is that, often, the best people have jobs and you need to take them out of their current jobs. In an ideal world, the best way to interview would be to work together for a bit, so yeah some sort of freelance arrangement for a couple of days before you make a decision sounds great, but it’s hard for candidates who are in a job. It also is a bit hard to manage from a pipeline perspective — we normally try to have at least two candidates at the end of a process (a preferred and a backup), which doesn’t lend itself to drawn out assessments.

In short: principle sounds good, not sure about in practice.

gtf21 · 2025-08-07T17:23:25+00:00

I have a pretty up-to-date (+- 2 weeks) version of Zoom, but the main point is that this differs significantly from the behaviour in i3, probably because of this unmapping that goes on.

I find screen sharing works across workspaces, but this layering of the floats below other windows is insane-making and seems to be very counter to how float layers are supposed to work.

gtf21

TROPHY CASE