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

201–210 of 320 posts

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

#201

Post by nextaccountic »

adrian_b wrote: post #199
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…

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 times (if not worse) but its standards for documentation is at another level

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

#202

Post by bionade24 »

Quothling wrote: post #177
koito17 wrote: post #17

Earlier quoted context omitted.

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…

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.

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

#203

Post by yakshaving_jgt »

lp4v4n wrote: post #16

I'm not a Haskell developer and I hadn't heard of this company "Scarf" before. As much as I respect this guy who tried to work and push an alternative ecosystem, it's hard for me to shake off the impression that, rather than due to Haskell compile time, he moved to python because it's easier to find developers for it and it's the de facto scripting language for LLMs. No problem about that, of course. Running a compan…

I run my company on Haskell purely for economic reasons. Aesthetics doesn’t come into it.

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

#204

Post by yakshaving_jgt »

hedgehog wrote: post #95

I don't have the experience, how high are Haskell compile times such that a switch like this is worth it? I have some experience with generated Python, Rust, and TypeScript, and I have not found that compile time is enough of a concern that it would offset additional safety of a stronger type system. Like some of the siblings I'm now starting to do experiments with Lean and other tools to get even stronger assurance…

Long compile times can be a problem. It’s also a problem that can be managed. I think this is overstated in the article.

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

#205

Post by yakshaving_jgt »

I’ve been running my company on Haskell for a similar length of time.

Long compile times can be an issue, but it’s an issue that can be managed.

Would I scrap Haskell in favour of Python, now in the age of agentic coding?

No. No I would not.

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

#206

Post by cwillu »

antonvs wrote: post #137
tonyarkles wrote: post #76

Earlier quoted context omitted.

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

Part of the issue is probably that Haskell build performance is perfectly fine for local development, even on rather large systems. But in commercial production environments, CI pipelines tend to want to build everything from scratch every time, and that slows everything down. Rust has the same issue. Both languages, by default, compile all their dependencies from source, rather than obtaining precompiled artifacts f…

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.

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

#207

Post by fjdjshsh »

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…

The problem in Scarf's case wasn't Haskell's type system, but the long compile time for even small changes.

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

#208

Post by ohmahjong »

sheept wrote: post #179
DanielHB wrote: post #164

Earlier quoted context omitted.

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

Why do you need both Biome and Eslint/Prettier?

I'm not who you replied to, but we use Biome for 99% of the linting/formatting, and then an eslint plugin for a few specific i18n scenarios that Biome doesn't cover.

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

#209

Post by newaccountman2 »

trollbridge wrote: post #117
newaccountman2 wrote: post #108

Earlier quoted context omitted.

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…

> Python doesn't have anything even close to something like SQLx, which is a natural fit in Rust because of how Rust macros work.

I'd be interested in hearing/discussing more about this. I was very surprised, when I embarked on my side project, that Rust's options for SQL ORMs all seem so weird.

I think what you are referring to is the derivation of FromRow and stuff with SQLx, right?

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

#210

Post by zelphirkalt »

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…

Yes, changing a type checker tool is not done easily in larger projects, or on the fly, as they all have different edge cases, where they don't infer well enough, or are more lenient than another tool.

I have switched type checker recently in my own Python projects from zuban to ty. ty seems to work better, and is not a one man show/bus factor of 1, though I respect the work that has gone into zuban by its creator. But ty doesn't understand mypy configuration in pyproject.toml ...

I imagine switching a type checker in a bigger project and with more people involved to be a bit of a PITA, until everyone has adjusted their development environment/tooling. Best one can do is research beforehand which tool suits one best, test it, and then stick to it, unless it has unbearable failures.

Post reply on HN