Is this our last chance to use fun programming languages at work?

Do you care what programming language to use?

I often think about reddit discussions, where someone genuinely asks how they can find a Haskell job, for example, and there are always people who advise against looking for a job based on the language (instead of answering the original question). I get it. I understand arguments for both sides, but I won't argue for either. Some care 80% of the time, some don't care 80% of the time.

A different way to look at this is from the perspective of mainstream vs niche programming languages. Because if you are obsessed with a programming language, you are likely obsessed with some niche, esoteric language. And if you are not obsessed, you are probably using something more or less standard; the good old "nobody ever got fired for choosing Oracle".

Those aren't the same, but bear with me. I'll repeat myself, not arguing for any side, I want to establish that there is a conflict: within a team, a company, a wider industry, wherever. There are people with different values and interests.

Another very new conflict is about the use of LLMs. Once again, some people are all about it, some refuse to use it, and all sorts of in-between.

If we overlap those, we get conflicting quadrants. It’s a simple illustration ‒ conflicts are rarely two-dimensional. But conflicts are not fun. Sure, some people love conflicts and thrive in conflicts, but for normal people, constant conflicts are not fun. If most people on my team are in one quadrant and I'm in another, I have to deal with it: either suppress my needs, argue, change companies, or whatever.

I've been thinking about this, and while I was looking at a project at work, it clicked: we can have our cake and eat it too (one group can have it and another can eat it). We can have successful and less-conflict teams over multiple quadrants.

So, I'll tell you the story about this little project, and maybe it can give you hope or inspiration in some dark, turbulent times.

A story about a little project

About 2 years ago, I wanted to migrate an existing internal dashboard to PureScript. The existing one was part of the legacy system that nobody wanted to touch, let alone extend. So the bar was quite low.

My goals were to 1) quickly migrate basic functionality to unblock the migration of a larger legacy system, which was driving me crazy, 2) make it composable and extendable with the lowest possible friction: have copy-pasteable components and allow people to integrate TypeScript and JavaScript components easily, 3) showcase PureScript and get people curious (spoiler, this didn't bear fruit).

It was never a goal to spread the PureScript usage; the arrangement with a team and tech leadership was to give it a try for a few of weeks, and then consider or plan a rewrite to TypeScript. I did an mvp (including the migration of core functionality) in my free time because there was no time for that during work hours. As a plus, I got a video about PureScript+shadcn/ui and a template out of it.

I believe one of the worst, unprofessional stunts that one can do is to introduce something that nobody can maintain. It can soil the reputation of the thing forever. I had an experience where someone used Haskell for a project, which had terrible management and plans from the beginning ‒ it was doomed to fail. Because it sucked, people quit. Eventually, nobody could or wanted to maintain it. Guess who was a scapegoat? Years later, people who don't even know what Haskell looks like were blaming it (and the dev team) for everything.

After I deployed the first version, it was just the two of us contributing. My accomplice had no prior PureScript experience and first hated it: mostly because of the tooling and compilation errors. But, he still contributed more code and functionality than me. And, in a couple of weeks, we got it to a pretty big state. And it wasn't even on our team's priority list; we were doing it in the evenings and between things.

Things were going pretty well, the project was growing, and then we went from copilot to the llm-assisted coding era. It's really big now. A lot of annoying things that used to be managed manually are now behind this nice ui: a bunch of customer support tools, dev tools, a bunch of product configurations, some analytics, and exploration tools. A huge portion of that code isn't human-written. Quite successful.

Why it works well and what we can learn from this

Why it works in a specific case

One of the main reasons it works (and scales) so well is that it's a stateless app (ofc we persist users' dark/light mode preference), and consists of simple flows. Also, when we let the llms loose, we had a solid project with a bunch of code, a lot of good copy-pasteable code (for what it's worth).

Each tool doesn't affect the rest. The only problem is organizing everything and not cluttering the ui, but that's more of a fun puzzle than an actual problem. In this context, I'm not afraid of any potentially bad or slow or whatever changes affecting the rest of the tools; there is no need for wild smoke tests or QAs.

For example, one person wanted to add a new fraud-prevention tool. They aren't part of our team and have never touched PureScript before. We had a five-minute chat, I shared the repository and told them, "Look, as long as there are secure endpoints, there isn't anything else to worry about, really". The project's readme is just npm install and npm start, so don't think that we have something sophisticated going on. They opened a pull request the next day, the code looks pretty good and consistent, and ui looks nice and friendly.

Which is fun and brings us to the most exciting part.

Why it works despite being functional

There were always concerns with steep learning curves. People bring this up most times someone mentions Haskell, Scala, Rust, or any other non-mainstream language.

This is no longer a serious argument.

The contribution entrance level is pretty low now. I definitely don't want to generalize and pretend like every contribution is equal, that this applies to acquiring proper skills, or anything like that, and I'm also not talking about open source.

But, in work environments, there are opportunities now to have good human code (I would go as far as to say, good functional code) and open the gates to various contributors. And if you have a higher bar then llms can deliver, you can always refactor and polish the code as needed.

As a bonus, we can lower the fear of maintainability and bus-factor. Microsoft says they are going to use llms to rewrite everything to Rust, so if somebody out there was brave enough to claim that, surely, we can be brave enough to introduce new technologies at smaller scale.

If somebody hates your Haskell tool at work, what stops them from rewriting it over the weekend? It has never been easier. I only had experience with migrating Ruby, JavaScript, and Python code to functional languages, but I'm pretty sure it works the other way around.

And it also extrapolates to making libraries. If someone says: "Oh, no! There is no Haskell SDK for a new hyped technology!" We can just laugh at them and send them back to 2025! Sorry. This is one of my favorite internal jokes.

In the case of PureScript, we don't even need to rewrite libraries ‒ we can just generate FFIs (PS-friendly bindings) to existing JS/TS libraries. We can also generate TypeScript code that uses those libraries and then generate PS bindings to this code instead...

For instance, we use shadcn/ui and have a couple of graphs integrated already, but not all of them. A couple of months ago, I wanted to investigate how the data looked somewhere (to work on improving caches), just once. Llms are pretty good at making quick charts ‒ it doesn't want to use shadcn/ui and prefers using radix charts directly. But I don't have to maintain it, so who cares?

(There is a chance I'd need it again next time, and I still haven't learned, but that's a different problem)

I don't want to go through a bunch of complaints and myths; the last two things I want to mention are tooling and errors.

I don't have an exact venn diagram, but plenty of people who complained about Haskell tooling, for instance, are now using chat as an interface to their code. So... yeah... Make your own conclusions.

But the situation with compilation errors is even more interesting. These errors ‒ in Haskell, PureScript, and so on ‒ are a huge pain point for many inexperienced and experienced developers. Talking about this has been in my backlog for a long time. Long story short, 90% of the time, if not more, the compilation errors are actually really good and precise. The problem is that they are often too precise. The compiler tells them exactly what the problem is, but in the words and concepts they don't understand. Because if they did, they wouldn't make the mistake in the first place.

firstLetter :: String -> String
firstLetter xs = head xs

• Couldn't match type ‘Char’ with ‘[Char]’
  Expected: [String]
    Actual: String
• In the first argument of ‘head’, namely ‘xs’
  In the expression: head xs
  In an equation for ‘firstLetter’: firstLetter xs = head xs

0 || True

• No instance for ‘Num Bool’ arising from the literal ‘0’

I'm not defending those errors, by the way. They still suck. For humans. But guess what, they are really good for the machines. Feed those suckers to llms. No need to be scared of compilation errors.

Why it works by virtue of being functional

On this project, we used to be cautious with llm-generated code, but at some point, we ended up with a couple of modules that only Claudius reads and edits. Once, I was curious and wanted to check what we had there. There were 10 states for different in-flight statuses ‒ a common thing, when one action is happening, we don't want to allow others. So, each action/button had its own flag/state and checked all the others (9 checks) to determine if it should be disabled. It's terrible.

So, if you look at one change or PR at a time, it's fine ‒ each one is just adding a normal state, nothing special. But if you take a step back and look at the bigger picture ‒ hell. It was a quick and easy fix to go from 10 states to 1.

Refactoring and dealing with tech debt are quite important, but could be scary.

This is a point for languages with fearless refactoring, like PureScript. I can't imagine how JavaScript developers, for instance, can survive this long term.

But that is me, right now, on a specific project. This is not an argument for an FP future.

Who cares what programming language to use?

I just want to know. Do you care what programming language to use? What are you doing about it?

Do LLMs care what programming language to use? How does it affect things you care about? How will it affect?

*This is February 2026; regardless of your opinion and experience, there is a chance, not a 0% chance, that programming languages will matter less because of the new abstraction level. But they might matter more.

Could it be our last chance to choose and care about programming languages?

I would love to ramble, speculate, and expand on this more, but probably some other time.

Also for that project, my side quest was to get people excited about PureScript, maybe teach a couple of people. This failed. Nobody really wanted to, and there is not much incentive at this point.