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

221–230 of 320 posts

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

#221

Post by gbacon »

nextaccountic wrote: post #201
adrian_b wrote: post #199

Earlier quoted context omitted.

The only complaint against Haskell was about long compilation times. I agree that short compilation times are very desirable, but I do not see why Python must be the solution for that. I do not know whether Haskell can be compiled quickly, but from my experience, I am very certain that short compilation times are easily achievable for languages with good static type checking, especially with compilers that have diffe…

> The only complaint against Haskell was about long compilation times. There is also this > How do we make library docs full of copy-pastable, realistic examples, not just beautiful types? Which is useful for humans as well as agents. Haskell indeed has a very bad track record of documenting its libraries. For many people, just having the function signatures is documentation enough. Rust is equally bad at compile tim…

> For many people, just having the function signatures is documentation enough.

You make a fair point about a documentation gap. The first step is always defining the problem. Wanting to add lots of realistic examples sounds like a wish for more tutorial or beginner-friendly content. Do you see the problem differently?

On the other hand, a given pure function type only has only so many possible implementations — why tools such as djinn and MagicHaskeller exist or why Hoogle is actually useful, unlike the horror of searching for every `void (*)(const char *)` in C.

https://hackage.haskell.org/package/djinn

https://hackage.haskell.org/package/MagicHaskeller

https://hoogle.haskell.org/

From that perspective, Haskell docs tend to be more expert-friendly — perhaps a rationalization, granted — which seems ideally suited for an in-IDE model to help bridge between developer intent and typechecked code. However, this comes at the expense of putting in the reps to rewire the developer’s brain to think in functional terms and the resulting mind opening and horizon expansion to think new thoughts she wasn’t capable of even considering. In these days of LLMs, fretting over that particular opportunity cost may be thinking nostalgically about the loss of craftsmanship in fine, well-balanced buggy whips.

In the limit now, will all programming be strictly literate?

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

#222

Post by zelphirkalt »

alexbezhan wrote: post #188

I find the need for type systems is less important now. and thats me saying this after 15 years of coding in Java, Scala, Kotlin, Typescript. Now I am using Elixir and incredibly surprised by how little I need static types. They are useful, but less needed now. Never could believe I would say that. But I'm the most productive I ever been. I get bugs of course, but they are related to queues lengths, retries, api erro…

You probably have built very solid concepts/ideas about what types are in the program and how to name things, so that they make sense, and all other things that lead to a program being useful and easy to read, over the course of those 15 years. The situation might not be the same for more junior devs.

But also Elixir's paradigm is not the same as lets say some PHP slinging or JS. It encourages a stricter functional style, that already makes for better code than what many people produce in languages like JS and PHP, or Python.

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

#223

Post by ErroneousBosh »

threethirtytwo wrote: post #133
ErroneousBosh wrote: post #34

Earlier quoted context omitted.

> I can't imagine using a language without a good type system to catch all the junk the LLM produces One approach would be to not use LLMs.

Another approach is career suicide. Both moves are isomorphic in many companies today and will be pretty much all companies in the future.

I don't really understand your comment. Are you saying it's "career suicide" to not use AI slop?

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

#224

Post by newaccountman2 »

trollbridge wrote: post #216
newaccountman2 wrote: post #209

Earlier quoted context omitted.

> Python doesn't have anything even close to something like SQLx, which is a natural fit in Rust because of how Rust macros work. I'd be interested in hearing/discussing more about this. I was very surprised, when I embarked on my side project, that Rust's options for SQL ORMs all seem so weird. I think what you are referring to is the derivation of FromRow and stuff with SQLx, right?

I don't paticularly want to use an ORM. What SQLx does is a bit different - it statically analyses the SQL in your program against the database and ensures the SQL is valid. This means you have rock solid assurance your program won't have database syntax errors at runtime. Basically it's just one less thing to worry about, and it's ideally suited for LLM-generated code.

Oh ok, I think I am using it wrong lol

I remember that being one of its "pros" when I was going over options with the LLM, but now, I just have a bunch of raw SQL strings in my codebase and sqlX's main use in that project, off the top of my head, is just instantiating Rust objects from the raw results with `FromRow` (it's probably doing more than I realize; I am not as connected with the code as I want to be, using LLMs to move fast to launch a couple features before revisiting a lot of the mess).

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

#225

Post by gbacon »

camkego wrote: post #146
aviaviavi wrote: post #73

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.

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.

https://devblogs.microsoft.com/typescript/typescript-native-...

https://github.com/microsoft/typescript-go

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

#226

Post by diegocg »

woodruffw wrote: post #212
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…

(Note: I work on Python tooling.) > for some reason we need 2-3 static analysis tools just for typechecking I don’t follow: you need one type checker, of which you have several options. It’s arguably not ideal to have more than one option, but you should never need to run more than one. - no tool understands each other's comment directives In general, all type checkers in Python support the `type: ignore` directive,…

If things were that simple...

I have to use more than one Python type checker because there is not a single one that works. Not only different tools catch different issues. They also have different bugs, and different configuration requirements. Different teams have different preferences.

It's a nightmare. If Python taught me something about typing is that a language that doesn't have a clear definition of types in the reference implementation, it will never get it fixed with external tooling.

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

#227

Post by rr808 »

alexbezhan wrote: post #188

I find the need for type systems is less important now. and thats me saying this after 15 years of coding in Java, Scala, Kotlin, Typescript. Now I am using Elixir and incredibly surprised by how little I need static types. They are useful, but less needed now. Never could believe I would say that. But I'm the most productive I ever been. I get bugs of course, but they are related to queues lengths, retries, api erro…

Scala was a dead end. Kotlin an obsolete workaround. Java though is now awesome, esp if you can ignore Spring. Should be more popular in the tech world.

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

#228

Post by mbac32768 »

adrian_b wrote: post #199
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…

The only complaint against Haskell was about long compilation times. I agree that short compilation times are very desirable, but I do not see why Python must be the solution for that. I do not know whether Haskell can be compiled quickly, but from my experience, I am very certain that short compilation times are easily achievable for languages with good static type checking, especially with compilers that have diffe…

Sounds a bit like surrender here.

There's no reason to read the code anymore.

The LLMs produce it inhumanly fast.

They can usually debug and fix problems faster than Haskell can compile the project.

Meanwhile the open source communities are in basic denial about AI, so trying to change things by making compilation faster or advancing a Haskell interpreter are going to meet with fierce resistance.

Whatever. Give up. Just ship Python.

I sympathize.

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

#229

Post by typesanitizer »

whateveracct wrote: post #81
benced wrote: post #78

Earlier quoted context omitted.

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.

Go compiles things at package-level granularity. You only need to recompile your reverse dependencies on making changes. Also there's build caching available out-of-the-box, as well as some support for test caching.

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

#230

Post by brainless »

dnautics wrote: post #211
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…

> I can't imagine using a language without a good type system have you tried? i use elixir and carefully watch the agents and its very seldom making typing mistakes (elixir is in-between, it's typed but only as a checker). ultimately typing doesn't help as much because it's nonlocal information. if the system can locally infer what the shape of functions is, it's way better.

"i use elixir and carefully watch"

- I do not watch agents, at all. Rust and Typescript. When I use Typescript only I have some guidelines so that we build the stack to be as strict and type driven as possible.

Post reply on HN