Live data from Hacker News

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

avi.press

81–90 of 320 posts

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

#81
post #78

Earlier quoted context omitted.

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.

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.

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

#82

I write a ton of Python code. Modifying code without static types is difficult and error prone. If a function needs a new argument, all the callers have to pass it and all of their callers recursively. Maybe the calling function is just a function pointer that has been passed around and not searchable. I love Python for small tasks and tasks that are not critical if they fail.

I also write a lot of python code. Ported 2 companies from python 2 to 3 too (idk why that keeps happening to me).

Lots of modern (...3+) python code uses type hints and a type checker. It can be as strict as you'd like it to be, which is exactly how I like it. It's what pulled me away from ruby.

Meanwhile, static languages are too often a giant pain in the ass, and in return for writing a lot of annoying code, you get in return guarantees that only really apply within your process's memory. And in a microservices world... you're actually realistically using the protobuf type system. Which generates just fine for python. And then "internally" you can use python's type checking where it helps, and if it doesn't help, then for that bit of the code, simply don't use it (and write "true" python).

I also find that a HUGE problem in the world is that programmers just. can't. help. themselves. They LOVE to over-define. LOVE IT. It's a siren's song!! Static type systems are a trap for the part of our brain that loves to architect. One of my favorite things about python is that it helps programmers _let go_. Not everything needs to be an interface. It's python. Everything is already an interface. Now just write the code without all the distracting 20 layers of indirection. And if we ever need one more, it's python - it's practically already there. Just make a new type, put @property on some methods, and you're good.

Obviously there are times I'd not use python. I could foresee myself writing Rust if I had to do code where correctness was of utmost importance (like, crypto, or embedded software for a medical device where someone's ventilator is hooked up to it, or similar). But if nobody's going to die (so... medical and cryptography...) then I'm using python almost no matter what I'm doing. And I'll use numpy or write a C module if I actually end up needing true CPU-bound performance for something.

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

#83
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…

OCaml works incredibly well with LLMs.

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

#84
I am writing couple of State machines and DSL in Haskell.

Haskell is great, once you write code, chance of certain kind of bugs appearing is very low.

Biggest problem i've is i develop on Apple Silicon and can't cross compile to x84 linux which is most common deploy platform for servers

Compare this is to Go, which is what i use for almost everything else, cross compile, copy to server and there you go! So simple.

this causes a lot of pain and suffering and slow development loop in Haskell.

I'd use Haskell for more things if someone solves this issue.

Please haskell community, come up with a way to solve this issue. It wouldn't be a problem if i've to install a JVM like we've for Java.

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

#85
post #72

OCaml is such an obvious solution to their problem that I'm shocked it wasn't even mentioned. You get fast compile times without sacrificing type safety.

I posted this above but honestly OCaml makes vibe coding so nice. I went back to go after a few months with OCaml and it was deeply frustrating

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

#87
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…

Personally been experimenting in Lean 4. LLMs understand it, can be given simple rules to improve it. Typing is strong, proofs are solid, and it compiles quickly.

On the contrary, for a small rust project, I had to clean out 180gb of cargo nonsense from the last ~3 days worth of compiles on a single, narrowly focused topic branch.

The library situation might be funky, but I'm also learning Lean 4 by hand. The tooling & lsp integration is lovely.

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

#88

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

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

#89
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…

Very interesting that I followed a very similar reasoning and settled on F#. Tells me that our process must have been very similar.

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

#90

"Hammers are now a very popular tool, and one can move quickly building exclusively with hammers, so we have decided to construct buildings strictly using nails, no more screws, bolts, or any other kind of fastener shall be used going forward."

You say this as if it were necessarily irrational.

Clothes became chain-stitched (and later lock-stitched) because machines could chain-stitch. If there were a super-efficient hammering machine, it could be better to figure out ways to use nails to replace screws in designs than to hold onto screws just for nostalgia's sake.

Post reply on HN