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

111–120 of 320 posts

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

#111

Post by markasoftware »

tonyarkles wrote: post #77
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 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 same time it has like half a dozen caches for different purposes and doesn't feel generally elegant. It saddens me that (a) cargo can't do this afaik and (b) its hard to package Bazel packages under nix. I'm not sure what other system has a shared unlocked cache.

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

#112

Post by iLemming »

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

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

#113

Post by whateveracct »

hunterpayne wrote: post #97
whateveracct wrote: post #81

Earlier quoted context omitted.

Golang has to compile the world iirc, so it'll need more and more time and resources as the slop grows in size. Whereas Python just interprets and gets off to the races. Feels like we had this discussion years ago as humans..the false promise of dynamic languages.

Python is preferred because Python programmers are cheaper than other languages. Not because of any sort of technical advantages. Its literally the worse performing programming language in popular use. And it uses invisible characters in its syntax. Truly, it is the VHS of our industry.

good point

it's a shame scarf is struggling so much they are pinching pennies :/

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

#114

Post by whateveracct »

iLemming wrote: post #112

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

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

#115

Post by eggy »

aryonoco wrote: post #89
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…

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.

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

#116

Post by iLemming »

whateveracct wrote: post #114
iLemming wrote: post #112

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 know that. Bumping GHC can still be relatively painful. Some language stacks are meaningfully easier on dependencies (not you Python), but can give you some other headaches (yes, you Python, damn you). Every PL in one way or another has some warts and ugly parts.

It seems the job of a senior software engineer these days is to make fun of programming languages on HN pointing out their flaws, while simultaneously keeping an eye, waiting on agents doing "thinking".

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

#117

Post by trollbridge »

newaccountman2 wrote: post #108
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 general I agree with you. I think expressive type systems are superior, and they are even better in the LLM era. I would quibble though that Python's is actually pretty good at this point, and, despite what the below poster is saying, straight-forward to set up and use. I am still perplexed that the author chose Python over Rust or Scala or TypeScript though, especially given they presumably want to migrate a Haske…

I'm perplexed by that too. We are migrating from Python to Rust simply because Rust is more suited towards unattended agentic loops, and we want to move in that direction. The results you get from a harness/agent/LLM with Rust are simply better than Python because the agent gets much better feedback from the compiler when it makes dumb mistakes. Python doesn't have anything even close to something like SQLx, which is a natural fit in Rust because of how Rust macros work.

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

#118

Post by andersmurphy »

aviaviavi wrote: post #62
weinzierl wrote: post #4

Earlier quoted context omitted.

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.

The number of compiler runs doesn't matter as much as the total elapsed time it takes to finish the task. In just about every test we ran, LLMs are faster at building in Python than Haskell.

Lisp/smalltalk programmers have been going on about this tradeoff for a long time. It mattered before LLMs too. Lisp/Clojure repl allowing you to compile tiny parts of your program inside your running program is incredible for your feedback/iteration loop.

Ironically, this is also what makes them shine with LLMs, the LLM has access to the running program and can modify it while it's running to get feedback instantly.

Complex type systems are cool. But, they are not free. I say this as someone who's first programming language was Haskell.

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

#119

Post by crabmusket »

matt2000 wrote: post #5

I am increasingly wondering if we are in a post-language world in terms of development. Why would I ask an agent to write a server in anything other than the most efficient language, although efficiency can take several forms: runtime, token usage during development, and wall clock dev time (affected by slow compile times for example). My intuition is that type-safe languages with fast compilers are the best option.…

I felt similarly. I wonder why the author is so invested in Haskell specifically becoming an AI-pilled ecosystem and community when the choice of language rounds to not mattering?

Go is the perfect language for this new world. Its development loop is fast, it has types but not too much so, it is memory safe, it is easy to deploy and it runs efficiently enough for most line of business use.

Go was originally developed specifically for a world of interchangeable hard-working juniors, which is exactly what LLMs can scale up with only your budget as the constraint.

I'm wondering what advantage a hypothetical faster-compiling-Haskell would have in that world.

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

#120

Post by andersmurphy »

jimbokun wrote: post #37
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."

Maybe overly verbose but makes an important point. Slow compile times should have been a deal breaker for how they impacted human coders. LLM coding just makes the problem more stark.

Yeah compile times have always mattered. It's why games often have a scripting layer in lua despite the engines being C/C++.
Post reply on HN