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

#151

Post by pjmlp » Sat, Jul 11, 2026, 7:34 AM UTC

antonvs wrote: post #136

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…

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

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

#152

Post by forgotusername6 » Sat, Jul 11, 2026, 7:37 AM UTC

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…

I have heard "the poor type safety" argument from writers of strongly typed languages for many many years. Having written js and python for a large amount of my carrier I can count on one hand the number of times I've found a bug that was due to a type issue. With LLMs it has been the same pattern. They don't seem to produce issues with types.

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

#153

Post by jiehong » Sat, Jul 11, 2026, 7:38 AM UTC

That's a very fair point, and Rust shares this fundamental issue as well.

That's where one better appreciate the work being done in Zig to get incremental compilation in milliseconds.

The choice of Python is quite interesting, and a big swing in the other direction.

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

#154

Post by tezza » Sat, Jul 11, 2026, 7:47 AM UTC

forgotusername6 wrote: post #152

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…

I have heard "the poor type safety" argument from writers of strongly typed languages for many many years. Having written js and python for a large amount of my carrier I can count on one hand the number of times I've found a bug that was due to a type issue. With LLMs it has been the same pattern. They don't seem to produce issues with types.

well i’ve come across it loads, especially 1/2) during REPL style build outs and 2/2) calling libraries and frameworks you are not yet familiar with.

perl another offender… is it a hash? is it an arrayref? over time you get it right, but by trial and error and looping. json suffers this too, arrays different from strings, different from numbers etc, but opaque until checked and liable to change

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

#155

Post by IshKebab » Sat, Jul 11, 2026, 7:49 AM UTC

forgotusername6 wrote: post #152

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…

I have heard "the poor type safety" argument from writers of strongly typed languages for many many years. Having written js and python for a large amount of my carrier I can count on one hand the number of times I've found a bug that was due to a type issue. With LLMs it has been the same pattern. They don't seem to produce issues with types.

There's absolutely no way that's true.

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

#156

Post by sdeframond » Sat, Jul 11, 2026, 7:49 AM UTC

forgotusername6 wrote: post #152

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…

I have heard "the poor type safety" argument from writers of strongly typed languages for many many years. Having written js and python for a large amount of my carrier I can count on one hand the number of times I've found a bug that was due to a type issue. With LLMs it has been the same pattern. They don't seem to produce issues with types.

> I can count on one hand the number of times I've found a bug that was due to a type issue.

Most bugs aren't type issues until you make them be type issues by expressing some business invariant in types.

Refactoring makes an exception not being caught the same way as before ? Type issue. Mixing up some ids ? Type issue. Etc.

Now that can also be emulated with extensive tests. But isn't that a concern for OP as well ?

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

#157

Post by rtpg » Sat, Jul 11, 2026, 7:50 AM UTC

antonvs wrote: post #136

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…

> "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…

What would be your goto for the ML training pipeline?

I have the impression that Python basically wins by default in those spaces due to the lack of many good libraries in other languages (except for, like, C++).

But curious if this is just a very outdated view of the world

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

#158

Post by IshKebab » Sat, Jul 11, 2026, 7:50 AM UTC

antonvs wrote: post #136

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…

> "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…

Yeah Python seems like a bad choice. LLMs seem to write low quality Python compared to Rust, presumably because there is a lot more low quality Python in their training sets than there is for Rust.

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

#159

Post by sdeframond » Sat, Jul 11, 2026, 7:52 AM UTC

If loop time is a concern, I am surprised the author does not mention tests. Is it still worth it to wait for your test suite to run when an LLM can get it right quick ?

Edit: I dont quite buy that argument, in case it was not clear.

Edit2: oh, is it specifically about incremental compile time? In which case I understand that tests can be run piece-wise quick indeed.

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

#160

Post by phillc73 » Sat, Jul 11, 2026, 8:06 AM UTC

sroerick wrote: post #83

crux wrote: 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.

Which models have you found work best with OCaml?

I also went through quite a process to select a language to work with LLMs[1] before settling on OCaml.

I am not unhappy with the choice and find it works quite well, with relevant skills loaded, but I am always interested in others’ experience and understanding what they’ve discovered works well.

[1] https://news.ycombinator.com/item?id=48105850