I didn’t see any mention of cost. Only speed (which you can’t evaluate without cost). You probably can’t share for one reason or another, but I do wonder what the monthly token spend is looking like (and its derivative 
)
Yes. I understand the opinion that you’re voicing, and my opinion is different than yours. Fine.
IMO that can be orthogonal to having discussions about the technical merits and pragmatism of different tools or languages.
Can’t give specifics, but the token cost is negligible compared to what it would cost to build the same features without them.
So what would help you? Would a 10x faster compiler help?
8 Likes
It would until the module graph ur compiling 10xes and you’re back where you started 
From customer call → ticket filed → PR opened → PR reviewed and iterated → merged → deployed, we can sometimes have bug fixes live before I get off the call with a customer. Resisting this kind of productivity is not an option anymore.
That’s fair. Lispers and Erlangers have always been right that ability to update in place is a markedly different workflow. But a parallel, later, innovation was immutable, commodified, containers, where you deploy a completely new version of the app entirely, that had been CI’d, meaning you never have ambient state that builds up. (Emacs users occasionally just have to restart because of it.)
I think Unison is the perfect marriage of these ideas: compilation only compiles the declarations that changed, and only runs the tests which depend upon the declarations that changed: you soup up the test cycle. Then, you deploy a hash: meaning you can do an immutable deploy as before, but the unit of delivery is as cheap as Erlang.
I think that LLMs increase the throughput of the engineer, but arguably this was never the true bottleneck. I suspect that the inability to deploy an app instantly leads to a whole world of waste, layers and cruft (think: you add config files, you add plugins or whole DSLs, Terraform, Kubernetes, YAML, Helm, feature flags, ..), whole companies, courses, careers are built on this.
Maybe Unison or its ideas came too late. We’ve entered the slopocene and that will, at least for some time, distract mainstream attention from such things.
12 Likes
The answer is to make Haskell the best version of itself for the world we are actually entering. That means taking AI seriously as a first-class user of the ecosystem. It means caring about build times, onboarding, documentation, examples, tooling, agent workflows and marketing, more than we care about type system research.
I don’t subscribe to this growth mindset anymore. Haskell is many things to many people: production use is just one of them. It has a gigantic hobbyist / research community, and I can speak from experience from working at FP Complete and watching them literally dump a million dollars in wages and hosting costs on tools to make it better for industry (tutorials, build tools, IDEs, etc) and the Haskell world resisted. 10 years later I still see professional haskellers completely unaware of the streamlined workflows we setup. I’ve come to accept Haskell on its own terms. If it dies out and becomes irrelevant like Elm or PureScript, I’ll be fine and still enjoy it.
20 Likes
This is true at the majority of corporations. IC throughput isn’t a bottleneck.
Amdahl’s law is being ignored completely when it comes to AI. This creates an illusionary phenomenon where ICs feel supercharged but it doesn’t affect the corporation at scale proportionally.
And ROI isn’t being measured much at all. Which is astounding to me given the millions some companies spend on this stuff. There’s a pervasive set of wishful thoughts I keep seeing:
- AI is assumed to be what it promises to be. It is novel tech but has assumed an incumbent position.
- Productivity/ROI is assumed to be some function of LoC/PRs/etc. “Oh it’s not a perfect metric but it’s related right?”
6 Likes
Nice, adding to my list of awesome laws. Thank you!
1 Like
(haha yep it’s a great one. i originally learned it in my CPU design class but it applies universally. or maybe corporations are just CPUs of human souls 
)
It sure would!
I also think what would help us is more Haskell in the public training corpus so the models get better at Haskell, faster.
3 Likes
I can get behind the compile times argument, but I don’t see how it hinges on LLMs. Compile times are bad either way, and they’ve been a drag on productivity way before LLMs entered the picture.
6 Likes
It’s mostly because LLMs amplify how often you pay the “tax” of a long compilation, to the point of becoming a primary bottleneck for certain workflows.
1 Like
I presume the “certain workflows” involve large amounts of unreviewed model-generated code? In my workflow the bottleneck is the speed at which I can review the model’s output.
GHC may be slow, but I am slower.
15 Likes
I’d be curious to hear if Scarf considered sponsoring efforts to improve the tooling space?
Given the cost of switching stacks, I’m a bit surprised to read more time and money did not go towards the cache or build issues as well, and even more so considering you’re on the board of the Haskell Foundation.
I guess it’ll be interesting for you to compare both codebases once they reach similar maturity levels.
4 Likes
I guess it’ll be interesting for you to compare both codebases once they reach similar maturity levels.
Agreed! I will report back. Who knows.
I’d be curious to hear if Scarf considered sponsoring efforts to improve the tooling space?
Given the cost of switching stacks, I’m a bit surprised to read more time and money did not go towards the cache or build issues as well, and even more so considering you’re on the board of the Haskell Foundation.
Great and fair question. To be clear, we put in a significant time and money towards solving toolchain issues. That cost is precisely the problem!
Scarf has contributed meaningfully to the Haskell ecosystem, and I am proud of that. We’ve provided free analytics services for Haskell.org’s site and docs and we are starting to expand that for Hackage analytics too. We open source as much of our Haskell code as we can, and I contribute my own time towards HF effort (To be clear, I wish I could do more). Even more impactful than that is we have a very generous free tier of our paltform for all OSS orgs that we don’t directly monetize, so we pay for a lot of bandwidth and data processing costs that we donate to the community, though that’s not just Haskell-based projects. The result is we have much less spare cash to throw at efforts that may or may not have a concrete ROI. While I wanted to simply financially sponsor the HF, it was never something we could justify given all the other factors.
(An aside, I’ve long said internally at the HF board, that HF should find a way to make it compulsory for companies like Scarf to contribute financially. This proved to be an unpopular idea that did not go anywhere.)
3 Likes
I presume the “certain workflows” involve large amounts of unreviewed model-generated code? In my workflow the bottleneck is the speed at which I can review the model’s output.
No, there are tools to scale reviews now as well.
GHC may be slow, but I am slower.
If only there were tools to help you move faster…
doesn’t this essentially propose making Haskell/GHC not FOSS anymore?
I can’t help but feel that we’re moving further into the dark ages of computation abetted by LLM based coding agents. To me, LLMs optimize the search-engine copy-pasta programming style prior to vibe coding being a thing. LLMs make this cycle faster and seamless obviously.
If your organization’s computational problems can mostly be solved through a patch work of regurgitated code, then you’re probably in the happy spot of search-engine or LLM based coding practices.
4 Likes
No, I was proposing more like some kind of rate limits on Hackage that would target large commercial workloads, a la Open Infrastructure is Not Free: A Joint Statement on Sustainable Stewardship – Open Source Security Foundation . FOSS != hosting unlimited free storage and bandwidth. As you might imagine I was alone in this suggestion and support of it
2 Likes
Totally wrong. LLMs can solve novel problems that are very hard already. I had GPT crank for about 8 hours to solve an issue that stumped our whole team for years. Its solution saved us about $200k/year on our AWS bill!
4 Likes