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…
After 7 years in production, Scarf has reluctantly moved away from Haskell
251–260 of 320 posts
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#252same 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.
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
#253Wow. 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…
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#254Earlier 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.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#255Earlier 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.
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
#256That 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
#257Earlier 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…
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
#258Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#259Earlier 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 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
#260Earlier 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