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

91–100 of 320 posts

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

#91

Post by timcobb »

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

Right, they run tests too. A compiler is like a quick test before tests. How are you going to cut out that check and let the LLM "write it faster" is beyond me. The compiler catches errors across codebases that today's LLM can't economically or reliably put into context to perform similar checks. They're totally different tools, today.

Also, you can just compile less frequently.

But hey, if LLMs are what drove this person from Haskell to Lisp then all the power to them!

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

#92

Post by japgolly »

hackingonempty wrote: post #65
em-bee wrote: post #61

Earlier quoted context omitted.

just curious, can you point to more details to what happened with scala3?

The usage stats on GitHub are declining, for example. Devs are choosing Kotlin, Rust, and Go over Scala. IMHO there are a bunch of reasons * Scala 3 was a Python 3-esque disruptive event * Perception as an overly-complex kitchen-sink inclusive language * Kotlin took up the "better Java" mantle * Rust became attractive to devs not committed to the JVM * Go became less sucky * SBT is disliked and Metals was buggy and u…

There's definitely less Scala jobs on the market these days.

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

#93

Post by hunterpayne »

em-bee wrote: post #8
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…

exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is actually decent. so does this mean that the LLM writes code that is so good that the compiler does not find any more errors? or is it due to the nature of haskell that makes it hard to write bad code to begin with? or just that because the haskell compiler catch…

"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 compiler which is sometimes lacking in the real work cough Scala cough. The problem with strong types and program proving is that the juice just isn't worth the squeeze meaning the extra time taken doesn't result in reduced debugging time or improved code quality. I don't think that changes with LLMs. It just exposes the flaws more quickly.

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

#94

Post by hunterpayne »

pjmlp wrote: post #48
Tarean wrote: post #24

Earlier quoted context omitted.

Java can also have 15+ minute cold compiles on large projects if you kill all caches. It's less bad on smaller codebases because you don't have to recompile dependencies if you target a bytecode vm, but if you always gate feedback on a cold compile in a fresh VM you just aren't gonna beat an interpreted language But I'd look at people a bit oddly if they said: 'We didn't want to set up CI caching and compiled languag…

Additionally in modern Java there are even the options of AOT and JIT caches, which can be reused across runs. Or if staying on Linux, JVM snapshots.

javac doesn't really do a whole lot. Consequently, whatever compile time you are complaining about would be worse with any other compiled language. Most optimization work in Java happens at runtime.

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

#95

Post by hedgehog »

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 about system behavior.

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

#96

Post by timcobb »

aviaviavi wrote: post #73
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…

Main factors were (roughly in order): - None of us are experts in Rust, and we're all solid at Python. - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way). - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work.

> None of us are experts in Rust, and we're all solid at Python.

you don't need to be, you can learn Rust or whatever way-better-than Python language as you use it with an LLM! it's an amazing process.

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

#97

Post by hunterpayne »

whateveracct wrote: post #81
benced wrote: post #78

Earlier quoted context omitted.

Python has so many footguns for server work and the world's worst typing system. It sounds like Golang is perfect for your use-case

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.

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

#98

Post by hunterpayne »

em-bee wrote: post #61
pjmlp wrote: post #45

Earlier quoted context omitted.

Yes, and in Java/C# case, AOT compilation is also available. I would also add Kotlin, Clojure and F#. Scala not really as the compilation is not much better, and since the Scala 3 reboot, the ecosystem doesn't seem to be doing that well. The market opportunity for Haskell on the JVM is gone, although they are doing cool stuff with capabilities.

just curious, can you point to more details to what happened with scala3?

Just to put it in perspective, most Scala programmers rejected Scala3 before it was even written. The Scala team, in their infinite wisdom with a collective 2 years of professional programming under their belt knew better. Nobody switched and Scala2 has been slowly dying with their neglect ever since.

PS The Scala team should have been fixing their type inference engine which lacked some important features and needed a better (Horn clause based) architecture. They did a complete rewrite instead.

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

#99

Post by hunterpayne »

hackingonempty wrote: post #65
em-bee wrote: post #61

Earlier quoted context omitted.

just curious, can you point to more details to what happened with scala3?

The usage stats on GitHub are declining, for example. Devs are choosing Kotlin, Rust, and Go over Scala. IMHO there are a bunch of reasons * Scala 3 was a Python 3-esque disruptive event * Perception as an overly-complex kitchen-sink inclusive language * Kotlin took up the "better Java" mantle * Rust became attractive to devs not committed to the JVM * Go became less sucky * SBT is disliked and Metals was buggy and u…

I can't even describe how much I dislike SBT.

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

#100

Post by em-bee »

hunterpayne wrote: post #93
em-bee wrote: post #8

Earlier quoted context omitted.

exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is actually decent. so does this mean that the LLM writes code that is so good that the compiler does not find any more errors? or is it due to the nature of haskell that makes it hard to write bad code to begin with? or just that because the haskell compiler catch…

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

what i expect to change with LLMs is the benefit you get from automated testing. which is really what LLMs need. tools that tell you something is wrong may not speed up a human developer, but they will allow LLMs to make corrections by itself until the warnings go away. so while it may not be worth it to a human developer, it may well be worth it for an LLM.
Post reply on HN