Live data from Hacker News

After 7 years in production, Scarf has reluctantly moved away from Haskell

avi.press

161–170 of 320 posts

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#161

Oh wow, Haskell to Python. Interesting. They must have really wanted to preserve cascaded dependency headaches. ___ Please don't let your kernel panic, I'm being sarcastic. You never know the level of emotional attachment some HN people have to their tooling...

cabal hell isn't even a real thing anymore.....

I only use Haskell in hobby projects outside of work but somewhat regularly run into problems with package bounds causing conflicts or forcing some project on to an older GHC than I'd like. It's not cabal hell since its confined to one project and not system wide, but it's definitely a pain point.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#162
post #151

Earlier quoted context omitted.

> "At Scarf, we started doing all new API work in Python." Start the countdown timer for how long it takes them to discover that was a mistake. Nothing to do with Haskell, but good grief, LLMs do not in any way, shape or form save you from the deep, unfixable problems with Python. At the very least you need all the static checking machinery like Ruff, Pyright, and hefty unit tests that take the place of typechecking…

It is a win win situation, they get to write a new blog post about doing a Python to Rust rewrite.

Lol

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#163
The article makes a convincing argument that Haskell compilation is too slow for the fast code generation of AI. But python?

I have yet to experience a RHEL major version change that did not blow up all my tiny simplistic python scripts. I see the following options for using python: * run inside the container it was developed in * build your own python interpreter and environment and libraries and never use python pieces from the OS (i.e., act like a container without using one) * keep different versions of the code for different OS versions and use AI to rewrite all the code for the new OS version

Start to consider third party dependencies, and none of those feels tractable without an AI assist.

I've dabbled in C device driver code and kernel version differences were my only problem, not C. My perl scripts never break. My bash scripts rarely break. My dabbling in erlang didn't suffer from language version differences. My little elisp hasn't broken. Only python has inflicted this level of version pain. I have a colleague who says java has the same version pain as python, and from what I've seen from Jenkins maintenance he may be right, but I don't have colleagues who want to read java code, so I haven't written my own.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#164
post #17

Wow. Not a Haskell user, but a big user of other languages with expressive type systems (mostly Scala; some Rust). My experience is the complete opposite. I can't imagine using a language without a good type system to catch all the junk the LLM produces. In fact I thought people would move away from languages from poor type systems, like Python, given the cost of using languages with expressive type systems has decre…

Recently had to touch a Python project at work. Just setting up the editor needed me to use 2-3 tools out of: pyright, basedpyright, ruff, ty, mypy, and possibly other tools I'm forgetting that kind of do the same thing but throw errors in different parts of the codebase. Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago. In fact, one my company's greenfiel…

In my (really large) typescript project we have like 6 static analysis tools running[1]. Steps to get the project running: install nodejs, install package manager, install dependencies, run project.

The main difference is that in the JS ecosystem it is all installed at the project level, you don't need anything globablly installed besides the runtime and package manager (and even the package manager can be auto-installed as well if you set it up that way).

[1]: eslint, biome, prettier, scass linter, graphql-codegen, tsc, tanstack-router codegen. That I remember, might be more (although codegen might not be considered static analysis, it is needed for static analysis).

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#165

The article makes a convincing argument that Haskell compilation is too slow for the fast code generation of AI. But python? I have yet to experience a RHEL major version change that did not blow up all my tiny simplistic python scripts. I see the following options for using python: * run inside the container it was developed in * build your own python interpreter and environment and libraries and never use python pi…

uv is solving these problems for the kind of things Scarf is developing.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#166
post #115

Earlier quoted context omitted.

Very interesting that I followed a very similar reasoning and settled on F#. Tells me that our process must have been very similar.

Why did you choose F# over OCaml? I am in the same boat and evaluating both. Mainly systems programming, applications, etc.

Both of these are near useless for systems programming and predictable behavior when caring about performance.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#167
post #46

Earlier quoted context omitted.

It is a bit surprising, I'd have guessed the same. Although in hindsight I could believe that type systems aren't particularly strong as an anti-bug layer. They help. They're a big boon for coordinating large numbers of mid- and low- skill programmers though because it forces them to go further in documenting their function signatures and makes it much more obvious where the problems are when refactoring spaghetti co…

> I could believe that type systems aren't particularly strong as an anti-bug layer. They're absolutely huge for this, but you have to write code to take advantage of the guarantees that the type system can offer. As Yaron Minsky at Jane Street put it, "make illegal states unrepresentable". Stronger type systems make it possible to make more states unrepresentable. You end up with what amounts to static debugging - y…

Languages like C and Go are so weak in the type system that it barely feels better than fully dynamic languages.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#168
post #25

I strongly agree with the premise of this article, which is why I am surprised that the author moved away from Haskell to Python. For some time now it’s felt clear (or at least extremely) compelling that agents need fast compile times in order to be effective, especially when you’re working in parallel. But the other thing that has felt just as obvious is that agents need strong type systems and narrow guardrails in…

OCaml works incredibly well with LLMs.

LLM are string happy instead of using ADT with ocaml. That was my main pain point with it. Otherwise fairly happy, I would feel C#/.net core would be the best overall in term of language/platform.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#169
Very interesting! I honestly would have expected the opposite: I was optimistic about strongly functional languages in the age of AI. The more modular and side-effect-free your code is, the easier it should be to constrain changes, catch slop, and reduce LLMisms like spooky hacks-at-a-distance.

It looks like the issues are in the compiler and documentation so hopefully it’s fixable… I write in Python every day but I do miss smarter languages and I hope AI doesn’t fully obliterate them.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#170
The development workflow is changing, and Haskell as a language doesn't fit that new workflow anymore. The traditional strong type system basically forced you to spend a long time thinking before writing code. The upside is that this makes the code more logical and robust. But it's the exact opposite of the AI loop. It's not that the type system is wrong—it's that the toolchain that comes with a strong type system has itself become a bottleneck.

With AI coding emerging, a single person can now churn out 100,000 or 200,000 lines. And realistically, from my experience, once you go past 40,000 lines, it's hard to memorize everything. So what do you do? Human coding shifts toward writing tests and gates, and once you feel comfortable that things are safe, you add more features.

AI coding takes this to an even more extreme level. Learning Haskell is great for learning domain modeling—I learned domain modeling through Haskell myself. But now that AI has become genuinely useful, it seems like a fundamental shift in workflow is happening.

Realistically, for commercial competitiveness, the domain of code black boxes is getting larger. The number of lines a single person has to manage is increasing, but their cognitive limits haven't changed. Even the amount of background knowledge required keeps growing.

In that sense, I agree with the author's point. It's not that Python is a better language than Haskell, so people switched—it's that Python has almost no build-up process and it serves as the standard interface for AI models.

The value of a language as a product doesn't come from the compiler's excellence. It comes from its users.

Avi Press's article ultimately reflects the reality that if you can't stay ahead throughout the entire lifecycle, you'll fall behind your competitors.

Maybe I'm just echoing my own thoughts, but it's reassuring to see that a well-known programmer thinks similarly to me.

Post reply on HN