Live data from Hacker News

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

avi.press

251–260 of 320 posts

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

#251
post #231

Earlier quoted context omitted.

Languages like C and Go are so weak in the type system that it barely feels better than fully dynamic languages.

At least in C and Go, you can get structs where it's easy to reason about the fields. In Python, a "class" is simply a dict under the covers and (by default at least) you can add attributes to it after definition (as well as things like properties). So it's difficult to reason about what the fields are at any given time. And that's assuming people USE classes! I've seen code where all the state is in one giant ever-c…

I don’t believe that “reasoning” is very useful in large code bases written by multiple developers. If you are trying to be axiomatic and prove to yourself that the code is correct, there are a thousand different ways the part of the code may not support your axioms in ways that are not apparent. It’s better to have a handful of invariants that are well communicated to the team and a lot of tests.

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

#252
post #247

same argument to migrate from Haskell applies to Ruby as well. & ultimately this is why Java/JVM keeps winning & to a lesser extent Typescript. you benefit from the robustness of the JVM, compilation is fast, the language is fast enough. to apply to Javascript/Typescript - good enough, fast enough though will not reach performance of JVM.

>same argument to migrate from Haskell applies to Ruby as well.

I am not following. Why does it apply to Ruby? Ruby has likely 10 - 100x the size of open sources project and momentum behind it.

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

#253

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…

> "At Scarf, we started doing all new API work in Python." Start the countdown timer for how long it takes them to discover that was a mistake. Nothing to do with Haskell, but good grief, LLMs do not in any way, shape or form save you from the deep, unfixable problems with Python. At the very least you need all the static checking machinery like Ruff, Pyright, and hefty unit tests that take the place of typechecking…

Unfixable errors? Why unfixable? Python is Turing complete. I can see difficult to fix, but not unfixable. LLMs lower the bar to refactoring code mistakes.

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

#254

Earlier quoted context omitted.

You're exaggerating quite a lot. Biggest I've seen the cargo directory after 3 months of active Rust development was ~17GB. You can also limit it with an env var. I have capped mine at 10GB.

I’m at 227GB as I write this.

Many rust nightly versions + no clean / sweep / clean-all?

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

#255
post #32
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…

> Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago. Optional[T] is now T | None. Means exactly the same thing but doesn't require an import. Support for the older syntax presumably won't be removed for a long while regardless.

It is only pyright/basedpyright that flags Optional[T] as deprecated as far as I am aware. Optional isn't actually deprecated by Python or anyone else.

You can disable it in the pyright settings. In my opinion T | None is not a meaningful improvement and insisting on changing it everywhere causes a whole bunch of churn and needlessly makes code stop working on older Python versions.

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

#256
Hate to bring the whole Bun rewrite drama into this discussion, but it seems the Bun team thinks it makes sense to trade a potentially faster compile time in Zig to a likely slower compile time in Rust due to the claimed advantages of a memory-safe language with a robust type system.

That approach seems entirely counter to the claims in this post. Obviously, different teams can have different perspectives, but I'm surprised just how different they are (especially for someone on the Haskell board).

I'd love to better understand why the LLM flow works for Bun, but feels untenable for Scarf. Maybe the Scarf team could learn from the Bun team's approach?

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

#257
post #61

Earlier quoted context omitted.

just curious, can you point to more details to what happened with scala3?

The usage stats on GitHub are declining, for example. Devs are choosing Kotlin, Rust, and Go over Scala. 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 u…

I don't think that Devs making those chooses but business and industry forcing devs to explore other options. One of the main issues with Scala currently that is no good selling story anymore for a business peoples. Even Rust story with 'memory safety' very fragile because not a lot of businesses see it as huge issue which worth additional effort (probably only MS backing helps there).

In the past it was lot of selling points that business could see:

- 'better java' - more velocity over java without loosing anything

- 'type safety / FP' - less errors that cost money in production (backed by 'Typesafe/Lightbend' company)

- 'akka' - platform for distributed/concurrency applications (in pre kubernetes era was big demand for it)

- 'spark' - initially Scala was only way to use it fully

- 'twitter' - startup success story

- and few more

But now nothing from this list has any real meaning for peoples making decisions currently.

Kotlin actually suffer from this too as 'better java' not that big deal when java constantly improving.

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

#258

Earlier quoted context omitted.

I’m at 227GB as I write this.

Many rust nightly versions + no clean / sweep / clean-all?

“Linux System Requirements: 3.2MB [+ 17GB the first day]”

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

#259

Earlier quoted context omitted.

OCaml works incredibly well with LLMs.

Which models have you found work best with OCaml? I also went through quite a process to select a language to work with LLMs[1] before settling on OCaml. I am not unhappy with the choice and find it works quite well, with relevant skills loaded, but I am always interested in others’ experience and understanding what they’ve discovered works well. [1] https://news.ycombinator.com/item?id=48105850

I was very happy with GLM 5.1 and Kimi 2.7. I did see an improvement in GLM 5.2. I found it to be more realistic about what was and wasn't good architectural choices.

I have a pretty elaborate harness setup, I use my own spec DSL to plan and execute code. So what works for me may not totally apply to others.

I haven't used the frontier models in a few months, so I can't speak at all to this latest batch. When I switched over from frontier I found that what I lost in training data, I more than made up for with Pi harness.

Your process seems more thorough than mine. Mine was literally "I like camels". Switching over to OCaml I found wonderful - I had not worked with FP before and I found it delightful, it kind of cured my programming burnout a bit. I hand built a CRUD app in OCaml/Dream but still feel like a rank beginner, especially when it comes to actually writing code, lol. But I'm getting much better at reading it.

I think the typing and structure of OCaml is a great fit for LLMs, but also the proximity to other things like DSLs, formal proofs, and algebraic structures has tons of untapped potential.

I'm having an absolute blast with it. I like programming again.

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

#260

Earlier quoted context omitted.

OCaml works incredibly well with LLMs.

Which models have you found work best with OCaml? I also went through quite a process to select a language to work with LLMs[1] before settling on OCaml. I am not unhappy with the choice and find it works quite well, with relevant skills loaded, but I am always interested in others’ experience and understanding what they’ve discovered works well. [1] https://news.ycombinator.com/item?id=48105850

One more thing - just seeing your affinity for Julia. I built a fully interpreted Lisp in OCaml which you might find interesting. I added my email to my profile here, feel free to reach out.
Post reply on HN