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

211–220 of 320 posts

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

#211

Post by dnautics »

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

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

#212

Post by woodruffw »

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…

(Note: I work on Python tooling.)

> for some reason we need 2-3 static analysis tools just for typechecking

I don’t follow: you need one type checker, of which you have several options. It’s arguably not ideal to have more than one option, but you should never need to run more than one.

- no tool understands each other's comment directives

In general, all type checkers in Python support the `type: ignore` directive, since it’s standardized.

> each tool reports a different error in your codebase

This is a real problem, but I think you can avoid it (like most people do) by not mixing different tools that do the same thing together.

To my understanding, you’d have the same problem if you combined (e.g.) biome and eslint in a JavaScript codebase.

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

#213

Post by zelphirkalt »

DanielHB wrote: post #164
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…

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…

Although I also install such tools (linter, import sorter, type checker) locally in my virtualenvs in Python projects. It is possible to do so, but maybe not as straight forward. I have to give the JS ecosystem that much: With the project-local approach, they have done one thing right.

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

#214

Post by zelphirkalt »

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.

Can you name some example and explain what happens, that the user is left without indication of failures? I am asking, because I have not had such issues yet, but maybe I just don't know I had them?

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

#215

Post by woodruffw »

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.

(I work on uv.)

Can you say more? uv should always tell you if a wheel build fails, unless the build backend (which uv doesn’t control, unless you use uv’s own backend) decides to silently ignore a wheel build. This would be a bug in any given build backend IMO.

This is an unfortunate complexity in Python packaging: something like `uv build` can dispatch a wheel build for you, but the actual code that gets run as part of that build is often third-party build backend code that uv itself has little to no control over.

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

#216

Post by trollbridge »

newaccountman2 wrote: post #209
trollbridge wrote: post #117

Earlier quoted context omitted.

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?

I don't paticularly want to use an ORM. What SQLx does is a bit different - it statically analyses the SQL in your program against the database and ensures the SQL is valid.

This means you have rock solid assurance your program won't have database syntax errors at runtime. Basically it's just one less thing to worry about, and it's ideally suited for LLM-generated code.

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

#218

Post by pdimitar »

cwillu wrote: post #206
antonvs wrote: post #137

Earlier quoted context omitted.

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.

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.

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

#219

Post by Verdex »

alexbezhan wrote: post #188

I find the need for type systems is less important now. and thats me saying this after 15 years of coding in Java, Scala, Kotlin, Typescript. Now I am using Elixir and incredibly surprised by how little I need static types. They are useful, but less needed now. Never could believe I would say that. But I'm the most productive I ever been. I get bugs of course, but they are related to queues lengths, retries, api erro…

This isn't a great comparison.

Im not that familiar with elixir, but erlang is hands down the best dynamic language to build systems in. It feels like they made only right decisions. I can only assume that elixir has made improvements on that.

Meanwhile java and kotlin have the least useful types I've encountered in my career. Scala has some pretty powerful stuff, but it's like the c++ of powerful types. The ergonomics aren't great. Finally, typescript has a lot of impressive typing constructs but it really falls down on the runtime side (because javascript).

The real comparison to make would be erlang/elixir vs rust or ocaml.

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

#220

Post by DanielHB »

ohmahjong wrote: post #208
sheept wrote: post #179

Earlier quoted context omitted.

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.

Yeah we had some corner case that still required eslint, although I don't remember what exactly. We also have prettier for a few file types not supported in biome.
Post reply on HN