Earlier quoted context omitted.
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.
After 7 years in production, Scarf has reluctantly moved away from Haskell
61–70 of 320 posts
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#62I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."
This thought completely neglects the idea that Haskell probably needs significantly less compiler runs because every run catches more errors and gives more information about them. And that is not even considering how often the agent needs to run tests to get it right.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#63For what it's worth, I've been using Haskell in production at Bitnomial, a financial exchange, and LLMs + Haskell is an extremely productive combo. Since Opus 4.6, LLMs have been pretty clever at using fancy types with libraries like Servant and Beam. The expressiveness of the types, combined with feedback from the compiler, means that agents converge quickly to something that works. I don't think I've noticed agents…
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#64Earlier 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?
There were other breaking changes as well.
https://docs.scala-lang.org/scala3/guides/migration/compatib...
This naturally broke all the tooling.
Then you have Metals for VSCode InteliJ plugins, while the Eclipse plugin was dropped.
InteliJ plugin is much further than Metals, however there is the conflict of interests with pushing Kotlin instead.
Meanwhile most Scala shops have pivoted to also give feature parity on modern Java, and Kotlin, thus reducing the interest in using Scala in first place.
However as mentioned, they are doing cool stuff with capabilities at EPFL for Scala 3.
https://virtuslab.com/blog/scala/introduction-to-scala-3-che...
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#65Earlier 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?
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 unstable (and still slow)
* Suffers from the "we won't be able to find devs" problem where Kotlin, Rust and Go don't
* A bunch of community drama drove some devs away to Rust
I say this as someone using Scala 3 with ZIO effects system and Mill build tool and thinks it is fantastic.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#66I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#67Wow, another bunch of people who give up engineering to satisfy their addiction to speed.
if my CEO wrote this article, I'd quit [1] in an instant
[1] "quietly" while i found gig+1. oh and the private out-of-band engineering gossip and trash talk would surely be hilarious
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#68Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#69I'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…