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

281–290 of 320 posts

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

#281

Post by bionade24 »

woodruffw wrote: post #215
bionade24 wrote: post #202

Earlier quoted context omitted.

uv still can't build all wheels and afaik they don't intend to do so. Furthermore they leave their users with 0 indication that the build fails because the wheel is unsupported by uv. If I were a beginnner or intermediate, I'd definitely given up after some attempts of fixing the buildsystem/code of the wheel. I don't get how uv regularly gets recommended without any note about this.

(I work on uv.) Can you say more? uv should always tell you if a wheel build fails, unless the build backend (which uv doesn’t control, unless you use uv’s own backend) decides to silently ignore a wheel build. This would be a bug in any given build backend IMO. This is an unfortunate complexity in Python packaging: something like `uv build` can dispatch a wheel build for you, but the actual code that gets run as par…

It happened almost 6 months ago, trying to build https://github.com/remsky/Kokoro-FastAPI with uv. From what I can still infer from the dependency list & my shell history, the problematic dep had been pyopenjtalk. After building & installing this dep with pip, I was able to continue to use uv.

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

#282

Post by lancepioch »

psd1 wrote: post #176
pmontra wrote: post #135

Earlier quoted context omitted.

The issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.

https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.

If that grinds your gears, then also take a look at Pieter Levels

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

#283

Post by dnautics »

brainless wrote: post #230
dnautics wrote: post #211

Earlier quoted context omitted.

> 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.

I'm watching because I'm particular about architecture. current project (company runs on it, its jira-lite + obsidian + benchling + a lab notebook, mendeley + a lims + a hardware kiosk that uploads scientific measurements directly to the notebook, everything running on cqrs and quill delta for operational transforms) is like ~100k loc and most new features are trivial (i just added a pcr wizard) because claude knows what particular patterns i use (and they are deliberately chosen to be more straightforward that conventional elixir/phoenix), but i do catch claude trying to do something chaotic from time to time. i suspect sometimes anthropic is routing me to a dumber model, because i can sense it happening, and if i keep going, it will make things really bad from an organizational standpoint, abd i have to roll back, but if i go to bed and pick it up next morning its fine.

next features are integrating a small transformer i built to codon optimize and probably "slack" to better communicate with the 2 ppl who work for me.

is your rust+typescript project at that level of complexity?

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

#284

Post by dnautics »

vcf wrote: post #234
brainless wrote: post #230

Earlier quoted context omitted.

"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.

Similar for me, I don’t want to babysit agents . I’m sticking with Python for the libraries (data science ecosystem), but I find that imposing ty and a few reasonable ruff rules (imposed with pre-commit so the agent can fix things automatically) improves agent-generated code a lot.

architecture matters more. at least for now, you should watch (not babysit) your agent, because it will slop up your architecture while you're not looking.

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

#285

Post by pjmlp »

strobe wrote: post #257
hackingonempty wrote: post #65

Earlier quoted context omitted.

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

However Kotlin has Google's as godfather, want to develop for Android with the official tools? Kotlin it is.

And no, Oracle lawsuit hardly has a role into it, as Android is still mostly all about Java ecosystem, Gradle, InteliJ, Android Java gets updated even if sloooowly (Java 17 LTS currently).

Had this not been the case and it would be yet another JVM guest language.

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

#286

Post by andersmurphy »

cubefox wrote: post #132
andersmurphy wrote: post #118

Earlier quoted context omitted.

Lisp/smalltalk programmers have been going on about this tradeoff for a long time. It mattered before LLMs too. Lisp/Clojure repl allowing you to compile tiny parts of your program inside your running program is incredible for your feedback/iteration loop. Ironically, this is also what makes them shine with LLMs, the LLM has access to the running program and can modify it while it's running to get feedback instantly.…

> I say this as someone who's first programming language was Haskell. Amazing. How did that happen? Is it true that functional programming is only counterintuitive because almost everyone starts out with an imperative language?

Philip Walder (one of the creators of Haskell) was our lecturer for my CS introductory course. I'd never done any programming before then.

Yes, imperative languages were initially counter intuitive to me. OO was even worse. SQL was fine as it's more declarative/functional.

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

#287

Post by MrBuddyCasino »

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…

Same, the article is really solid but then they choose to migrate to… Python?

This feels like someone giving a great commencement speech, then proceeding to pull out a gun and shoot himself in the foot as the final act.

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

#288

Post by DanielHB »

bbkane wrote: post #231
DanielHB wrote: post #167

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…

The best thing React ever did to the JS ecosystem was hammer in on objects/maps/dicts being immutable. In modern JS it highly unnusual to see code modifying objects (except right after creating them) even though the language itself has no convenient means of representing that.

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

#289

Post by DanielHB »

doug_durham wrote: post #251
bbkane wrote: post #231

Earlier quoted context omitted.

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.

Yeah this is what I meant, structs are obviously a huge step up in type-safety but the ways you can abuse or bypass the typesystem in C and Go means you still have to be super careful about the memory your code hold, receive or returns.

I think Go developers don't think this is much of a problem because most of them are working on microservices where data is not kept around for a long time (usually a single request). And of course Go makes it a lot easier to handle data-access parallelism. So the benefits of a powerful type system are somewhat diminished in this scenario.

I think it is one of the reasons why Go devs don't see much benefit in Rust, the borrow checker is just not that useful in the context of isolated requests.

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

#290

Post by tome »

forgotusername6 wrote: post #267
IshKebab wrote: post #155

Earlier quoted context omitted.

There's absolutely no way that's true.

My experience is only anecdotal but I can assure you it is true!

It's easy to talk at cross purposes in discussions like this. There are two implicit claims

* Few bugs occurred due to type issues (which I think you are asserting)

* You can design your program with types so that what would be a bug due to a type issue doesn't compile (which IshKebab may be thinking)

Both of these can be true at once

Post reply on HN