[ghc]

I was puzzled by this article at first, but when you put it that way it makes more sense. The author also had a presentation awhile back about why Haskell is a terrible language for startups to adopt. I imagine that in the current venture environment vibe coding is being pushed heavily by investors since companies are effectively in an arms race where feature development cost is moving towards zero and investors don't care about individual companies because they have a portfolio of bets.

[pdimitar]

I don't think it has almost anything to do with vibe-coding. When I tried Haskell and OCaml some 3 years ago, they were infuriating in terms of tooling and just needless friction (don't ask, forgot, but it was mostly around package management and just entering a project and be able to run the program was a saga).

Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its tooling to not stand in my way. I want to be enabled, not be left a scarred veteran with badges of honor like "Managed to install 5 dependencies and compile and run! And it only took me 3 hours!" or some such.

Compare to Golang, Rust, Elixir, and no small amount of others -- you add a dependency, run a command, twiddle your thumbs 30 seconds, done.

I want to solve problems. Not troubleshoot tooling that should have been prod-ready 10 years ago.

[ghc]

I've been using Haskell for 20 years. I've been running a company built on Haskell for 10. I have a very large legacy Haskell codebase. I've invested in several companies built on Haskell. Your anecdote is about your own lack of familiarity, nothing more.

Yes, companies can get into trouble with Haskell compile times, memory use, etc., but enforcing disciplined coding rules and advances in tooling solved the majority of the problems by 2016.

We use LLMs to assist in writing Haskell and have for several years. We keep track of compile times to catch regressions and on our largest code base an agent-driven change takes an average of 96 seconds (as of this month) to compile. Agents looking to do quick compile checks during code writing can run with flags that make the compilation run in less than 5 seconds. In all cases, running out test suites takes a lot longer than compile times.

The only time this isn't true is when you compile from cold start, as you would when using multiple work trees...which is the expected behavior when vibe coding features. So yes, I believe the issues they're running into have a lot to do with vibe coding. Check out all their integrations...Haskell's probably a poor match for what they do, but vibe coding integrations is probably what they need to do to get new customers.

[pdimitar]

To comment separately: lack of familiarity is true of course but do consider your bias -- familiarity should come quickly and easily. Long gone are my days where I wanted to wear badges of honor and suffer through difficult tooling, and I am willing to bet that's true for a lot of programmers.

We want to iterate and progress. You likely are used to Haskell's tooling quirks long time ago. Everyone else outside of the ecosystem does not have that advantage.

[pdimitar]

IMO from the info given in the OP it seems to me that they never actually needed Haskell, not playing to its strengths anyway, especially if they felt Python was an adequate replacement -- which it absolutely is not if you value the compile-time finding of bugs, better known as "a strong static typing system". But that's a separate discussion vector.