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

141–150 of 320 posts

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

#141

Post by antonvs »

roenxi wrote: post #46
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 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 co…

> 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 - you debug your code at compile time.

Sure, it's still possible for runtime bugs to occur, but entire classes of bugs are eliminated, plus it becomes possible to have static assurances about program states about things that most language don't even try to express in the type system, like security.

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

#142

Post by adamddev1 »

The author talks about how Haskell needs to catch up to stay relevant in "the AI era."

> That means taking AI seriously as a first-class user of the ecosystem.

Honestly for me any time a language or a tool markets itself as "for the AI era" or takes agents seriously as first class users, I run. It's a bad smell for me.

I'm happy that there are things like Haskell that are still focussed on correctness and sanity, and not pandering to the AI psychosis driven on by the market.

I am really disturbed by this ideological framing of "it's the AI era now" "we have to let the agents run" "speed, speed, speed" "if you don't learn to engineer with random garbage, you will be left behind!!"

Some of us will need to leave the cult of the empire of AI and live in caves like the desert fathers, committed to actually crafting correct things.

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

#144

Post by youre-wrong3 »

adamddev1 wrote: post #142

The author talks about how Haskell needs to catch up to stay relevant in "the AI era." > That means taking AI seriously as a first-class user of the ecosystem. Honestly for me any time a language or a tool markets itself as "for the AI era" or takes agents seriously as first class users, I run. It's a bad smell for me. I'm happy that there are things like Haskell that are still focussed on correctness and sanity, and…

[flagged]

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

#145

Post by bkovacev »

YZF wrote: post #121
whateveracct wrote: post #81

Earlier quoted context omitted.

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 just interprets and blows up in production more like it ;) Also so slow. But bad Golang is full of `any` and turns into a Python in disguise.

What is exactly slow when building APIs in Python and compared to what? :)

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

#146

Post by camkego »

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.

You might not like Microsoft but they did a video on why they re-wrote the last version of the Typescript compiler in Go. Basically, because of LLMs. It's worth viewing even if you don't decide to go with Go.

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

#149

Post by pjmlp »

These335 wrote: post #44
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…

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.

Having been around for quite some time, and having used several dynamic languages, my pet peeve isn't types.

Rather I prefer not to be in the same spot I was in 1999 - 2001, with Tcl, and every now and then rewriting code into C, for the application to actually deliver within the performance deadlines.

Python is the only mainstream dynamic language where runtime support for dynamic compilation is such an hassle, where the alternatives do exist, yet are mostly ignored.

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

#150

Post by pjmlp »

antonvs wrote: post #138
timcobb wrote: post #91

Earlier quoted context omitted.

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

> 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.
Post reply on HN