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

171–180 of 320 posts

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

#171

Post by tpoacher »

> Now there is a third place: code generation time. The model can often avoid the mistake before the compiler ever sees the code.

This is doing a lot of heavy lifting here. How do you even know a mistake has been "avoided", and safely, for that matter? The kinds of mistakes the AI will miss are the worst kind: subtle logical mistakes, buried inconspicuously within boilerplate code, hard to detect or reason about, until one day you wake up to find that your database has been replaced by a rickroll video.

Also, it's odd that they moved from Haskell to completely untyped python ... python may be no Haskell when it comes to type safety, but typing+mypy/mypyc goes a very long way.

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

#172

Post by antonvs »

pjmlp wrote: post #150
antonvs wrote: post #138

Earlier quoted context omitted.

> But hey, if LLMs are what drove this person from Haskell to Lisp then all the power to them! I didn't see Lisp mentioned in the article. They moved to Python. Which is certainly a choice.

Yeah, basically all the Lisp without the machine code generation machinery.

Having worked professionally with Common Lisp, I can tell you that’s not even remotely true.

Besides, “machine code generation” is not a fundamental part of Lisp. Some of the most famous implementations were pure interpreters.

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

#173

Post by dizhn »

UltraSane wrote: post #30
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…

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 used TS and Go mostly with LLMs and they are very good at them. Python has been fine too honestly. A surprise entry is Flutter/Dart. They are very good at it. I think it's a mixture of types, the good tooling and focused documentation.

All of these I run in a cli that has automatic LSP in it so that's a huge factor too. The agent is automatically told when there would be compile time errors as well as linter issues.

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

#174

Post by pjmlp »

antonvs wrote: post #172
pjmlp wrote: post #150

Earlier quoted context omitted.

Yeah, basically all the Lisp without the machine code generation machinery.

Having worked professionally with Common Lisp, I can tell you that’s not even remotely true. Besides, “machine code generation” is not a fundamental part of Lisp. Some of the most famous implementations were pure interpreters.

Such as? Having known Lisp since 1996, and avid digital archaeologist, I wonder which famous implementations are those.

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

#175

Post by antonvs »

DanielHB wrote: post #167
antonvs wrote: post #141

Earlier quoted context omitted.

> I could believe that type systems aren't particularly strong as an anti-bug layer. They're absolutely huge for this, but you have to write code to take advantage of the guarantees that the type system can offer. As Yaron Minsky at Jane Street put it, "make illegal states unrepresentable". Stronger type systems make it possible to make more states unrepresentable. You end up with what amounts to static debugging - y…

Languages like C and Go are so weak in the type system that it barely feels better than fully dynamic languages.

I agree, I was referring to powerful type systems.

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

#176

Post by psd1 »

pmontra wrote: post #135
hunterpayne wrote: post #93

Earlier quoted context omitted.

"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good com…

The issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.

https://xkcd.com/224/ lol

Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing.

In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.

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

#177

Post by Quothling »

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…

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, a pandas and pyarrow.

I personally prefer the fake typing in Python because it fits well with our defensive programming style with very low abstraction and little to no adherence to DRY. Since Python naturally force you to deal with runetime assertions rather than getting you to do compiletime checks that then don't actually offer any form of safety at runtime. Which is obviously not a very technical argument, but it just feels a lot cleaner rather than having to juggle the two.

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

#178

Post by DonHopkins »

pjmlp wrote: post #174
antonvs wrote: post #172

Earlier quoted context omitted.

Having worked professionally with Common Lisp, I can tell you that’s not even remotely true. Besides, “machine code generation” is not a fundamental part of Lisp. Some of the most famous implementations were pure interpreters.

Such as? Having known Lisp since 1996, and avid digital archaeologist, I wonder which famous implementations are those.

Even Emacs Lisp has had a byte code compiler since forever, and since Emacs 28 it compiles to native machine code via libgccjit.

Toy lisp interpreters are easy and fun and everywhere, often written in lisp itself, but the same books that teach them go on to teach compilers. SICP chapter 4 is the metacircular evaluator, chapter 5 is the compiler. That ordering is the point: interpretation is the pedagogy, compilation is the destination. Lisp was designed to be easy and efficient to compile (so was Self, and that tech lineage runs straight into HotSpot and V8).

The archaeology cuts the other way too. The only famous pure interpreter was LISP I on the 7090, and within two years Hart and Levin's Lisp 1.5 compiler (1962) became the first self-hosting compiler in any language: written in Lisp, compiling itself. Lisp practically invented compilation as we know it.

And today: SBCL doesn't even interpret by default, a form typed at the REPL is native code before it runs. Clojure compiles every form to JVM bytecode. Interpreters exist, but nobody ships them as the production path outside of pedagogy.

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

#179

Post by sheept »

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…

Why do you need both Biome and Eslint/Prettier?

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

#180

Post by yxhuvud »

japgolly wrote: post #88
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…

It's about the feedback loop being so slow. Agents often compile and run tests to verify their work

The fun part is that the argument holds just as true for humans that write code - we also run tests to verify our work!

Which is basically what people liking dynamic languages have said all the time - types is only good as long as the overhead they bring doesn't cost more.

Post reply on HN