Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

avi.press

Post reply on HN
Print view View original

71–80 of 320 posts

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

#71

Post by lenkite »

weinzierl wrote: post #4
muragekibicho wrote: post #3

I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."

This thought completely neglects the idea that Haskell probably needs significantly less compiler runs because every run catches more errors and gives more information about them. And that is not even considering how often the agent needs to run tests to get it right.

I am wondering whether next year there will be re-write of Scarf after the vibe-code degenerative collapse of their source code into un-maintainability. At some point, the LLM patch/fix cycle will devolve into straitjacket.

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

#73

Post by aviaviavi »

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…

Main factors were (roughly in order):

- None of us are experts in Rust, and we're all solid at Python.

- Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way).

- Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work.

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

#74

Post by subversiontaco »

Every time I see a post like this it somehow turns into a conversation about AI. Are there any studies on this? How much better are typed languages for LLMs. I would expect the amount of data and scaling laws to have more of an effect on an LLMs coding capabilities than the language itself.

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

#75

Post by tonyarkles »

subversiontaco wrote: post #74

Every time I see a post like this it somehow turns into a conversation about AI. Are there any studies on this? How much better are typed languages for LLMs. I would expect the amount of data and scaling laws to have more of an effect on an LLMs coding capabilities than the language itself.

I mean, in this particular case one of the biggest pain points they’re talking about are just straight up build times. An LLM that can produce a patch in 5 minutes and then has to wait 15 minutes for a build… to then put together another 1 minute patch and wait another 15 minutes for a build… that’s not ever going to be able to compete with Python where there’s no build time at all.

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

#76

Post by tonyarkles »

em-bee wrote: post #8
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…

exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is actually decent. so does this mean that the LLM writes code that is so good that the compiler does not find any more errors? or is it due to the nature of haskell that makes it hard to write bad code to begin with? or just that because the haskell compiler catch…

> what's the solution here? speeding up the haskell compiler? if that were easy, would it not already have happened?

I suspect you’ve nailed the answer: it’s probably not easy, although it’s also possible that it just hasn’t ever had a lot of attention paid to it because it’s been generally fast enough for their user base?

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

#77

Post by tonyarkles »

zeendo wrote: post #60

I am surprised by this take, honestly. We're a Haskell shop (and have been for over 10 years now) and are finding agentic development with Haskell to work pretty damn well. Cold compile times in Haskell are painful indeed. Our development practices don't really cause us to do that much - even with agents. It's unclear to me if the development practices at Scarf that cause them to hit this pain often are worth it if i…

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 but by having a separate source tree, it does trigger the cold compile problem. Two agents compiling the code in separate worktrees are working on entirely separate builds (great!) but that means there’s no shared compilation cache between them (not great). Is that something that’s tripped you? Have you found a good solution?

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

#78

Post by benced »

aviaviavi wrote: post #73
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…

Main factors were (roughly in order): - None of us are experts in Rust, and we're all solid at Python. - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way). - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work.

Python has so many footguns for server work and the world's worst typing system. It sounds like Golang is perfect for your use-case

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

#79

Post by woadwarrior01 »

muragekibicho wrote: post #3

I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."

Granted LLMs aren't very good at the ML family of languages. Isn't vibecoding a lot safer with a typed language? Going from Haskell to Python is going from one end of the typing spectrum to the other.

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

#80

Post by jbritton »

I write a ton of Python code. Modifying code without static types is difficult and error prone. If a function needs a new argument, all the callers have to pass it and all of their callers recursively. Maybe the calling function is just a function pointer that has been passed around and not searchable. I love Python for small tasks and tasks that are not critical if they fail.
Post reply on HN