Haskell is dead.

I'm saying that because look at this

right here. After 7 years in production,

Scarf has reluctantly moved away from

Haskell. Now, for those that don't know,

Scarf is one of the large Haskell

companies out there running Haskell in

production. I know a lot of you right

now thought, "Well, the white the white

paper language?" Yes, the white paper

language actually does have a few

production cases and this is one of

them. Now, normally when I make this

joke, I inevitably there's somebody in

the comments losing their mind.

"Actually, YOU JUST DON'T EVEN

UNDERSTAND. YOU'RE SUCH a stupid idiot.

The type system is Okay, okay. Hey, the

white paper it's just a joke, okay,

buddy? Okay, guy. Hey, you're not that

guy, pal. Just back up Just back off the

keyboard, okay?" Now, normally I

wouldn't necessarily be that excited

about these type of articles, but the

reason why I am excited about this is

that this Avi Press fella right here,

not only did he start a company with

Haskell, the company is successful using

Haskell, and he serves on the Haskell

Foundation and haskell.org committee.

He's been using it for the last 16

years. He's claimed he's a huge fan of

it and it's the undeniably most

important programming language in his

life. Like, he loves Haskell. And when I

see somebody who really loves something

decides that they want to move away from

it, I have to know why. Because me

personally, I I recently made a video

where I said I'm done with Go and it's I

I was a huge fan of it. I loved using Go

and then I kind of felt like the North

Star of Go just no longer mapped up with

the North Star of what I wanted out of

the language. And so, I'm always

curious. Whenever I see somebody who's

done something for a long time, why do

you change? What is the thought process?

Because I want to learn from you. Now,

in this video I'm going to be doing

something that I Again, I typically try

not to do, but we're going to be making

yet another tech prediction due to the

last two tech predictions being so

just spot on, I think I got a good third

one and it maps up with this article,

okay? So, we're going to go over this

article, the reasons why he's changing.

Honestly, there was a section caught me

completely off guard, and then there was

a follow-up section that caught me even

further off guard. I just couldn't even

believe it. I just I was even I I felt

like my eyes were just like just must be

misreading it. But, before we get to

this monoid in the category of

endofunctors, I'd like to first say

thank you to the sponsor. Oh, monad,

that's just a monoid in the category of

endofunctors. Hey, is that HTTP? Get

that out of here. That's not how we

order coffee. We order coffee via SSH,

terminal.shop. Yeah, you want a real

experience? You want real coffee? You

want awesome subscription so you never

have to remember again? Oh, you want

exclusive blends with exclusive coffee

and exclusive content? [music]

Then check out Crown. You don't know

what SSH is?

>> Errors on

>> Well, maybe the coffee's not for you.

>> Terminal coffee

in hand,

living the

dream.

>> All right, welcome back, my little

digital monads. So, now, to kind of talk

about this article, first, Obvi gives

kind of like a what they have done with

Haskell. They have done a whole bunch.

They built a bunch of production

systems. They have a bunch of

high-performance Haskell, which I didn't

even really realize was possible. But,

what they what it comes down to is he's

saying is that a huge problem is

compilation and ecosystem friction. That

they just spend so much time trying to

optimize, build. They're effectively

doing so much time as a company what

probably should be handled at a language

level. Like, the language should be the

one providing all these available, you

know, tools. But, instead, every company

that ends up using Haskell has to come

up with their own bespoke or unique

caching system. They have to come up

with their own ways to be able to have

really solid developer environments, CI,

and everything. And this is a like a

major burden on the company. For a long

time, that was workable. Our team knows

the language and tooling deeply. We knew

where the sharp edges were and we mostly

lived with it. Then AI changed the

trade-offs. Yes, I This is one of the

kind of the the first of many surprises

for me. I I was a bit surprised why AI

made these changes because I would

assume that AI would have actually

performed quite well with with Haskell.

And the reason being is that Haskell has

a very deep and provably correct type

system and which gives really excellent

feedback about the things that are going

wrong. So, I would assume that a thing

like AI would have just gone hard on the

Haskell system, right? Like it's

actually just a Haskell fanboy

underneath. That that the matrices and

Haskells, they're like little you know,

they're bedfellows at this point. But

apparently,

I was wrong. And his argument goes a

little something like this.

Historically, I thought about errors as

something you caught in either one of

two places, at compile time or at run

time. Now, there's a third place, code

generation time. The model can often

avoid a mistake before the compiler even

sees the code. And as the models get

better, the relative value of catching

every possible issue at compile time

changes. Very surprising, by the way,

for a Haskell person to say this. This

is like This is the most nuanced ass

take I've ever seen a Haskell person

have. Because typically, it's like, "Oh,

no, no, actually the answer's Haskell."

Oh, what are you I don't even need to

hear what project you're building. The

answer's Haskell. Haskell's like the

greatest, okay? Here, let's get started

on the white paper together. Next year,

we'll get started on the project, okay?

Me and you, babe. Now, this is really

where the first big like, "Oh my gosh."

comes in. This is not to say that type

safety has become worthless, but the

cost of type checking matters more now.

So, the compilation times matter a whole

bunch, but this is a Haskell person

telling you that types aren't worth the

same. If type checking takes too long,

it's no longer worth it as much. Very

very shocking. And his argument goes,

"If an LM can produce a working

implementation in a few minutes, but

your compiler steps takes dramatically

longer, then your language and build

system has become the bottleneck in

development loop. And that is because

with his project, the size of the scope

of the project, a cold build can take 15

minutes. That means if you spin off a

new agent in a new work tree, the

initial setup time includes a minimum

15-minute cold start build. Now, that I

can understand. Like, that's a lot.

That's a lot of CPU time, especially if

you have a bunch of people kicking off a

bunch of builds. You're spending a lot

of machine time just even getting to the

point of starting to make a query or an

LLM anything. And he makes an even

stronger point with this becomes

unbearable when you start using many

coding agents in parallel. This becomes

obvious if you haven't thought about it.

The longer and stronger your build times

are, the more computation or CPU time

that you need to have. So, if you have

multiple of these things running at the

same time, the build time goes from 15

minutes potentially to 30-40 minutes

because you have many things all

competing for the CPU at the same time.

So, this could actually become like a

major bottleneck. You couldn't do

anything with it. And if the model

you're using, say, Grok-4 5 super-duper

fast only takes 2 minutes to generate a

piece of code, and then it takes like 30

minutes to set up your environment, I

agree. That's actually kind of crazy. A

part that really floored me here is that

sometimes the loop is 20 seconds, and

that feels great. I can't even imagine,

personally, wanting to wait 20 seconds

to see if what I have programmed is

correct or not. Now, the program that

I've been writing for the last about

month and a half, it's almost up to

about 20,000 lines of code. So, it's not

a very big project, but if I go in here

and change an enum to just be a word

that doesn't make any sense in this

category, we clearly have an error right

here. If I go and do a full build,

you're going to see the result in

approximately what, 100 milliseconds? If

I keep on executing it over and over

again, it's just super, super fast.

Somewhere between 70 to 100

milliseconds. Now, these old eyes and

these old nervous system, I can't even

possibly respond to that level of speed.

And so, this type of turnaround is what

I am used to. I want to see this. This

is what I want out because I don't want

something as simple as compilation being

the bottleneck cuz that is kind of

crazy. So, I really think I understand

his general argument, which is just a

very practical side. It's not the

language. It's It's none of that. He

does make some basic arguments that the

people within Haskell, they really don't

want to actually make Haskell for AI

agents. None of them consider that

compile times to be a problem or they

actually feel like they want to go

anti-AI. Now, I'm not going to really go

into why I think that is good or bad. I

don't You know, it's just like I don't

really care. You want to You can run

your language however you want to run

your language. That is up to you. That's

hey, that's cool on you, bro. I don't

care. So, this is where the second big

kind of wow moment, the one that I was

completely taken back on. How we move.

Now,

there in the Haskell world, they are the

ultimate typed Andy. They love types.

They use types. They use types. They use

them to death. They just want them. They

love them. They sleep with them. They

read books about them. And now they're

going to change. They're going to change

their whole ecosystem. I think the very

natural kind of move here is like, "Oh,

okay. You think 20-second loop feels

great. Okay, Rust. This would be a

pretty natural move to Rust. You get all

the benefit of like a really specific

strong compiler language. You have a lot

of similarities with Haskell with a lot

of the deeper types within it. So, okay.

We're probably going to move over to

Rust is what you're thinking."

Wrong, son. At Scarf, we started doing

all of our new API work in Python.

Now, this is not something I saw coming.

A company that loved Haskell moved to

Python. Okay, hey, maybe I just

misunderstand the situation, but that

just seems like This is like an M. Night

Shyamalan turnaround right now. Like,

what is happening to my life? Okay, AI

is upending all cultural norms, and I

don't think I like it right now, okay?

Because my Haskellers are supposed to

look down on someone like me who uses a

language like Odin, okay? They're

supposed to look down on me because I

don't even have some types that is to

their elegant nature of some types.

Yeah, sure, I have unions and I have

some other nice fancies in this, but I

do not have the quality of catamorphism

or whatever they call it laying upon my

eyeballs like they have. Meanwhile, I'm

over here and I'm still trying to

explain monads like a burrito, WHICH IS

JUST NOT

THE HIGHBROW WAY OF DOING THINGS. BUT,

when I see a company transition from

Haskell to Python, it's crazy.

Bro, that's crazy to me. The thing I

like the most about all of this is this

paragraph right here. So, after kind of

explaining how they transitioned over to

Python, he says the following. The

result is hard to capture in a single

metric. PR throughput did not obviously

go up. Commit volume is noisy. Lines of

code is a bad proxy. Thank you.

>> [applause]

>> You can tell this guy's a real engineer

cuz he doesn't have just literally one

head takes.

I produce a lot of code like no one

cares if you produce a lot of code,

okay? That's stupid. It makes you look

stupid. You act stupid when you say

those things. So, shut the up with

the monads. Anyways, development count

is money because it includes previews,

infrastructure, and other noise. But,

the productivity change is visible in

the shape of what we can now ship with

high effort, minimal oversight, and even

what we can ship fully automatically.

From customer call, ticket filed, open

PR, PR reviewed, iterated, and merged,

and deployed, we can sometimes have

fixed live before I get off the call

with the customer. Resisting this kind

of productivity is not an option

anymore. And I think I I think we're

going to see a lot lot more of this. For

better or for worse, I think when it

comes to simple bug fixes, I think you

can largely just let AI kind of go

pretty autonomous as long as you have

enough kind of e-vows and review process

set up, it should pretty easily be all

automatic at this point, especially

small stuff. But, at the end of the day,

I think this is going to become just

like a giant uh focus for a lot of

people, which is a lot of the kind of

the noise of development can be shed off

pretty quickly when you start using

these you know, the old LLMs. Because

imagine if he was still on Haskell, he'd

be on a customer call. He's going to be

like, "Okay, we can start taking care of

that, but first we need to wait 30

minutes for this build to get kind of up

and running. Then after that build gets

up and running, it needs to go to CI,

then CI needs to prove it out. Okay,

that's going to be another huge long

build wait time. Then after that is

done, then you're going to need to do

build the deployment, the actual

artifact itself. Now, that's going to

take another long time. And then

finally, it gets off to production. Like

it could you can see why this takes a

long time. It's like that one little

change requires hours of computation

time. And at the end, he talks a lot

about how Haskell's in real danger. I

actually recommend you reading this. I

think it has a lot of really good

insight into what it's like kind of

trying to run a company, be a part of a

language. Like what do you do when you

really deeply care for something, but

you feel that ends are odds with the

people who are also running it? A lot of

cool kind of takeaways within this, and

I just strongly recommend a good reading

for you. But I really wanted to talk

about that kind of top part, the more

practical boots on the ground like

I would just not have guessed if you

would have asked me compilation times

being the big culprit here, that caching

was really difficult. I knew the

ecosystem was kind of hard to work with,

but I did not realize it was to this

extent that even the experts are like,

"Tag me out." Also, let's just the

Python part. The Python part was nuts.

But now it's time for the prediction

that I said I was going to do. Now,

typically when it comes to uh some

development, especially in the kind of

the LLM day and age, what you have is

you have cost. That's one of the sides

of the triangle, right? And then you

also have speed. How long does it take

for the LLM to kind of do something or

be a part of something or to give good

feedback on all that. And then lastly,

you're going to have correctness. Now,

it kind of seems like for the last few

years, correctness has been the large

focus of a lot of these providers. I'm

thinking about like Fable, right? Fable

takes a long time to do anything, but

when it when it gives out is generally

it can be pretty close to what I would

like to see in production. But, the

speed is just atrocious and the cost, I

mean,

dang, I'm going to have to like give

away my inheritance for all of this. I'm

going to have no shoes and no shirt

after I get done using Fable. But,

nonetheless, you can kind of see this uh

By the way, is this Am I seeing Am I

seeing what I think I'm seeing here,

boys? Boys, am I

SEEING

>> [laughter]

>> ANY- OKAY, DON'T get me distracted by

the beautiful drawing. Now, my previous

prediction was that cost is going to

become something that's really

important. That we're going to start

seeing people really want to see cost

kind of going down and I think you're

starting to see that more and more. The

new Grok model is both fast and it's

also super cheap. The new Soul model is

like literally like 20 times cheaper

than the old Fables while being, you

know, approximately the same amount of

correctness. You know, they're all

within kind of a stone's throw of each

other. But, I think the next big thing

we're going to see is that speed is

actually going to take a huge front

stage step because as people start

realizing the speed of iteration is

really the most important thing cuz if I

can go and ask like, "Yo, give me three

implementations of this. I just want to

look at it. Like, what are we What are

we dealing with here?" And I get to see

like three different implementations of

something. If that could come back to me

in 3 minutes, like that is a gigantic W.

Even if it cost say a dollar more to be

able to do that, you would choose the

speed every single day of the week. And

so, I think that speed's going to become

the big new focus. And so, that is my

big kind of, you know, prediction for

the rest of 2026 is that that's what

we're going to hear a lot of people

talking about. The new fast models.

Okay, these are the fastest ones.

Anywho, this was a really awesome

article. Highly recommend you get all

the details out of it. Go take a read

out of it. Absolutely awesome. The 7

years in production and Scarf has

finally moved away from Haskell. It kind

of marks a a unique time period we're

living in. Like for me, this is the big

kind of flag for we're living in a new

time period that it's important enough

that even Haskell [clears throat] Andys

are saying, "Hey,

I need to change." That's

not something I ever thought I would

personally see. The name

is the prime imagine.