Live data from Hacker News

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

avi.press

181–190 of 320 posts

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

#181
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…

You always work in a virtual environment per project in Python, all dependencies are installed in the venv.

So same as JS then.

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

#182
Interesting. The major factor seems to be the latency of change-compile-test cycle.

I wonder if one of the reasons I've been getting such excellent results from LLMs with Clojure could be that they can immediately try things out in the running REPL. Rebuilding my entire application from scratch takes minutes, while connecting to a running system through nREPL and compiling single functions or namespaces takes less than a second.

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

#183

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've never done anything "serious" with haskell, just small personal projects. Mostly this is because I've found the ecosystem to be a pain - when I was trying stack stack was the thing to use but from what I can tell ghcup+cabal now work better.

If you push through that you end up with code written in a language people have used for formal proof (seL4 model is Haskell) and deployment wise a binary that +/- libraries you depend on ought to be reasonably portable.

I'm very surprised anyone would want to go the other way. Same ecosystem pain, plus you need to start shipping interpreters or containers, plus the language just doesn't really compare.

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

#184
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…

I've gotten best results with LLMs generating Go, Java, and C# code as they have the best combination of strong type systems and fast or no compile times.

I'd argue that any type system that don't support enforcing non-nil/nullability is not strong in any way and probably worse than not having any type system at all as they give a false sense of security.

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

#185

Wow, another bunch of people who give up engineering to satisfy their addiction to speed.

Yeah, I don't get it. There are so many real-world bottlenecks that it doesn't matter if you can edit the code 10x faster. It could even be beneficial to tactially slow down some parts of your SDLC.

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

#186

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…

It makes sense, Haskell is basically just python from the code perspective. If it's faster to generate code than to compile it you might as well just keep generating til it works for your specific task.

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

#187
post #115

Earlier quoted context omitted.

Why did you choose F# over OCaml? I am in the same boat and evaluating both. Mainly systems programming, applications, etc.

Both of these are near useless for systems programming and predictable behavior when caring about performance.

Jane Street uses OCaml in a domain where performance matters.*

*https://signalsandthreads.com/performance-engineering-on-har...

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

#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 errors, memory usage, performance, ... Bugs related to incompatible types are rare.

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

#189

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've never done anything "serious" with haskell, just small personal projects. Mostly this is because I've found the ecosystem to be a pain - when I was trying stack stack was the thing to use but from what I can tell ghcup+cabal now work better. If you push through that you end up with code written in a language people have used for formal proof (seL4 model is Haskell) and deployment wise a binary that +/- libraries…

I know several people who are serious Haskell users despite, like you, using it just for small personal projects. All of them are quite some way down the autism spectrum and will casually toss around Haskell concepts that require about 30 minutes of googling by anyone else present in the conversation to try to understand. Get two or more of them talking to each other and everyone else present is more or less excluded from the conversation... and this is something they're doing just for fun, not because they're paid to do it.

It could just be a coincidence of statistics, but it does cover every Haskell user I know (needless to say, these people are much smarter than I am).

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

#190

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…

My experience has been that the more type/safety checks the more chances there are of the AI getting stuck into a stupid loop

Because a lot of times it's missing the way of making the needed steps for the conversion (or it's just not obvious)

Sometimes it needs some nudging

Also this comment is a bit generic, it can also apply to cases where it's not an obvious "type check" but a redundancy that needs to exist but the AI can't get around

Post reply on HN