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?
After 7 years in production, Scarf has reluctantly moved away from Haskell
41–50 of 320 posts
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#42We 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.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#43If 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
#44Wow. 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…
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#45I 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 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
#46Wow. 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…
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
#47Another 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
#48Earlier 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…
Or if staying on Linux, JVM snapshots.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#49Languages 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
#50I 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.