Live data from Hacker News

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

avi.press

41–50 of 320 posts

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

#41
post #19
post #11

I'm curious about the choice of Python, rather than TypeScript. I find Ruby a very beautiful language, and Rails is an excellent web framework, but I need typed functions, record types and sum types. They help not just with correctness, but also as living documentation that lets me understand AI generated code. TypeScript provides discriminated union, but not exhaustive pattern-matching, and its syntax is a bit verbo…

python has optional types too now. if you could get the LLM to produce typed python would it be any worse than typescript?

Yes, because the code you (or the LLM) writes is only part of the equation; if you use third party libraries then it becomes an ecosystem problem. I'm not currently using much Python but my understanding is that the community has not yet aligned on typing nearly as well as the TS community has.

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

#42

We at Cachix have also moved on from Haskell about two years ago and I'm sure someone is going to make a comeback with a language that takes the lessons from it but starts from skratch. We need more general purpose Elm languages in the space.

Isn’t tgat language Rust, practically speaking?

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

#43
I like this article, but I would take some issue with the concept of the percentage of time taken up being a major issue.

If you go from taking 2 days to write some code and 20 minutes to type check (which does seem long, don't get me wrong, but still) to 10 minutes to prompt some code and 20 minutes to type check, that percentage increase to me isn't enough to justify switching.

You're still almost 2 days ahead, and converting those 20 minutes to 20 seconds are not going to make you ship a feature appreciably faster. But those types stand strong and I don't believe they can yet be replaced by an LLM believing they're correct.

Having said that, I also think that Haskell should massively speed things up. Having strong types if nothing else should surely produce some amazing type-checking speed wins.

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

#44
post #17

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…

I grew up on python and after working with Java I really came to appreciate types. However I do want to point out that big libraries like mpl pre-date most efforts for typing, so it is no wonder that they arent typed properly. A lot of these libraries are trying to improve this but it will just take some time.

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

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

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.

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

#46

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 is a bit surprising, I'd have guessed the same. Although in hindsight I could believe that type systems aren't particularly strong as an anti-bug layer. They help. They're a big boon for coordinating large numbers of mid- and low- skill programmers though because it forces them to go further in documenting their function signatures and makes it much more obvious where the problems are when refactoring spaghetti code because things break loudly.

Refactoring spaghetti has become easier in the LLM era because it can just read all the code, and there is now a skill floor on the programmers that kicks in somewhere relatively high. The benefits of type systems might have suffered because of that.

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

#47
Languages designers will have to make a choice whether to continue to design for humans or for big slop machines. The design goals are not compatible. This is obvious. I don't understand how anyone can miss such an obvious point.

Another obvious point is that an industry that runs on code slop will stagnate in terms of language an human tooling design.

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

#48
post #24

Earlier quoted context omitted.

I'm pretty sure that's the general trend and it will continue. But I do think what benefits LLMs is the speed and accuracy of feedback. Type systems cover the accuracy part, but haskell was killing them on speed. It seems like a strange choice to go so far the other way on accuracy when there's a lot of languages in between. But I'm not familiar with the project so not in a position to call it. It's not also really a…

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.

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

#49
post #47

Languages designers will have to make a choice whether to continue to design for humans or for big slop machines. The design goals are not compatible. This is obvious. I don't understand how anyone can miss such an obvious point. Another obvious point is that an industry that runs on code slop will stagnate in terms of language an human tooling design.

Robots need formal specification languages, to tame non deterministic compilers.

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

#50
This is a good post. AI has changed the programming language trade-offs and, as someone running a company that uses both Haskell and Python, I hope that Haskell can adapt to this new era.

I would like to add one additional observation, since we have been using both Haskell and Python in production for a long time:

Haskell excels at platform work, while Python excels at product work.

Our infrastructure teams work in Haskell (and also Rust nowadays), while our product teams work in Python. This gives us the best of both worlds (in my opinion): fast and rock-solid infrastructure on the platform side, and fast development speed and quick iteration cycles on the product side.

This setup has worked well for years for us, but it remains to be seen how and if this is going to change as well in the new AI era.

Post reply on HN