After 7 years in production, Scarf has reluctantly moved away from Haskell • Hacker News Board

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

#231

Post by bbkane » Sat, Jul 11, 2026, 2:53 PM UTC

DanielHB wrote: post #167

antonvs wrote: post #141

Earlier quoted context omitted.

> 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.

At least in C and Go, you can get structs where it's easy to reason about the fields.

In Python, a "class" is simply a dict under the covers and (by default at least) you can add attributes to it after definition (as well as things like properties). So it's difficult to reason about what the fields are at any given time. And that's assuming people USE classes! I've seen code where all the state is in one giant ever-changing dictionary and you have to pull out a debugger just to figure out what's IN the thing! God help you if you mispell a key!

Maybe you work with better quality code than I do, but I find Go's type system a lot easier to reason about than Python's.

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

#232

Post by bbkane » Sat, Jul 11, 2026, 2:59 PM UTC

Lyngbakr wrote: post #187

59nadir wrote: post #166

Earlier quoted context omitted.

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

Jane Street uses OCaml in a domain where performance matters.* * https://signalsandthreads.com/performance-engineering-on-har...

Jane Street has unlimited engineers and money to do this.

At least from the sidelines, it looks like they've built/forked most parts of the OCaml ecosystem to make it work (OxCaml, Dune was built by then, custom profilers, custom networking hardware, etc).

Of course a lot of their work is open source and can be used, but I wouldn't assume that it would be worth the effort to do something similar with OCaml yourself. Maybe it is! LLMs go brrr and all that.

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

#233

Post by bbkane » Sat, Jul 11, 2026, 3:08 PM UTC

markasoftware wrote: post #111

tonyarkles wrote: post #77

Earlier quoted context omitted.

Speaking as someone who has tried Haskell but hasn’t ever really gotten into it, but spends all day with a C++ codebase that also has long cold-compile times… I think the author of the post said they’re using git worktrees to be able to have multiple agents working on different things at the same time without stepping on each others’ toes. I’ve started experimenting with that myself and it’s great in a lot of ways bu…

Bazel maintains a system-wide cache that fixes this. At $current_employer a truly cold build (rm - rf the system cache) is 10 minutes or so. In a new worktree with a warm system cache it's under 60 seconds (still needs to build the worktree specific analysis cache). A fully warmed build is 10 seconds. Additionally there's no lock on that system wide build cache. For this reason alone I want to like Bazel. But at the…

The Cargo folks actually have caching funded for a bit (though I'm not sure how well it interacts with worktrees)! See https://rust-commercial-network.github.io/rcn/funding-direct...

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

#234

Post by vcf » Sat, Jul 11, 2026, 3:10 PM UTC

brainless wrote: post #230

dnautics wrote: post #211

Earlier quoted context omitted.

> I can't imagine using a language without a good type system have you tried? i use elixir and carefully watch the agents and its very seldom making typing mistakes (elixir is in-between, it's typed but only as a checker). ultimately typing doesn't help as much because it's nonlocal information. if the system can locally infer what the shape of functions is, it's way better.

"i use elixir and carefully watch" - I do not watch agents, at all. Rust and Typescript. When I use Typescript only I have some guidelines so that we build the stack to be as strict and type driven as possible.

Similar for me, I don’t want to babysit agents . I’m sticking with Python for the libraries (data science ecosystem), but I find that imposing ty and a few reasonable ruff rules (imposed with pre-commit so the agent can fix things automatically) improves agent-generated code a lot.

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

#235

Post by garethrowlands » Sat, Jul 11, 2026, 3:30 PM UTC

pseudohadamard wrote: post #189

zahllos wrote: post #183

Earlier quoted context omitted.

I've never done anything "serious" with haskell, just small personal projects. Mostly this is because I've found the ecosystem to be a pain - when I was trying stack stack was the thing to use but from what I can tell ghcup+cabal now work better. If you push through that you end up with code written in a language people have used for formal proof (seL4 model is Haskell) and deployment wise a binary that +/- libraries…

I know several people who are serious Haskell users despite, like you, using it just for small personal projects. All of them are quite some way down the autism spectrum and will casually toss around Haskell concepts that require about 30 minutes of googling by anyone else present in the conversation to try to understand. Get two or more of them talking to each other and everyone else present is more or less excluded…

The number one hard working concept in Haskell is parameterisation. A typical Haskell concept is just a concept, not a Haskell concept.

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

#236

Post by kstrauser » Sat, Jul 11, 2026, 3:46 PM UTC

pdimitar wrote: post #218

cwillu wrote: post #206

Earlier quoted context omitted.

The thing I hate about rust is that compiling a small app immediately creates 100gb of junk, and that junk doesn't live in the responsible project's folder, and that junk doesn't get cleaned up by anything.

You're exaggerating quite a lot. Biggest I've seen the cargo directory after 3 months of active Rust development was ~17GB. You can also limit it with an env var. I have capped mine at 10GB.

I’m at 227GB as I write this.

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

#237

Post by toolslive » Sat, Jul 11, 2026, 3:48 PM UTC

nextaccountic wrote: post #201

adrian_b wrote: post #199

Earlier quoted context omitted.

The only complaint against Haskell was about long compilation times. I agree that short compilation times are very desirable, but I do not see why Python must be the solution for that. I do not know whether Haskell can be compiled quickly, but from my experience, I am very certain that short compilation times are easily achievable for languages with good static type checking, especially with compilers that have diffe…

> The only complaint against Haskell was about long compilation times. There is also this > How do we make library docs full of copy-pastable, realistic examples, not just beautiful types? Which is useful for humans as well as agents. Haskell indeed has a very bad track record of documenting its libraries. For many people, just having the function signatures is documentation enough. Rust is equally bad at compile tim…

> Rust is equally bad at compile times

OCaml enters the room...

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

#238

Post by ulrikrasmussen » Sat, Jul 11, 2026, 3:55 PM UTC

koito17 wrote: post #17

noelwelsh wrote: post #2

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…

I had a similar experience as you. We normally use Kotlin for everything, but last year we had to do a small project in Python. Setting up the tooling and choosing the tools is quite overwhelming, and the inconsistency between what the tools actually consider type errors is incredibly frustrating. I am actually happy that the project failed and that we don't have to work in that environment anymore.

I think Python is probably good for many things, including scripts and as a starter language, but I don't understand how anyone can stand writing large software systems in it.

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

#239

Post by catlifeonmars » Sat, Jul 11, 2026, 4:00 PM UTC

The justification in TFA smell like premature optimization. A nominal bottleneck is just that-nominal. It’s a good thing to keep in your back pocket but you generally don’t want to expend extra effort optimizing something until you have to.

I suspect that the cost of long compilation times (preLLM even) was actually quite high and the author is discounting/excluding those other factors and focusing on LLM feedback loops primarily as their justification.

As an aside short feedback loops are important, but the article ignores one major reason why: humans learn most effectively when the time between action and feedback is reduced because the contents of our working memory degrades over time (take the explanation with a grain of salt). LLM has no such restriction, so the only thing that matters is that the codegen can keep up with the demands from the actual product.

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

#240

Post by Quothling » Sat, Jul 11, 2026, 4:25 PM UTC

bionade24 wrote: post #202

Quothling wrote: post #177

Earlier quoted context omitted.

UV, Ruff and Pyrefy and you're set. As someone who works with Python, Typescript and C/Zig quite a lot I don't disagree with you on Typescript, but I'm not sure why you'd pick Typescript over Python. Bun is kind of awesome, but it's also kind of unfinished, but if you go with the default Node I find that the setup for security compliance is next to impossible where Python can do most things with it's standard library…

uv still can't build all wheels and afaik they don't intend to do so. Furthermore they leave their users with 0 indication that the build fails because the wheel is unsupported by uv. If I were a beginnner or intermediate, I'd definitely given up after some attempts of fixing the buildsystem/code of the wheel. I don't get how uv regularly gets recommended without any note about this.

We get UV to generate a requirements.txt and then use the Python and Pip which is available on the official Microsoft container images we use for Azure container apps once it hits production. I've never had any issues with the build system in development though.