Comment by rebeccaskinner | Hacker News Reader

Comment by rebeccaskinner | Hacker News Reader

Parent Full thread

I think you're taking a particular view of things that can work, but it's not the only correct view.

> The talent pool and availability of the language

There are certainly more Javascript or Python developers out there than Haskell developers, but I think it's wrong to imply that Haskell is a hard language to hire for. There are more people out there who want to work with Haskell than there are Haskell jobs, and picking Haskell can be a really great way to recruit high quality talent. It's also quite possible to train developers on Haskell. A lot of companies hire people who don't have experience with their particular language. The learning curve for Haskell may be a bit steeper, but it's certainly tractable if you are hiring people who are eager to learn.

> The ecosystem of libraries and ancillary tools like monitoring/debugging/observability

Other languages have _more_ of these, but it's not like Haskell is missing basic ecosystem things. I actually find that Haskell is pretty nice with this stuff overall. It's not quite as automatic as what you might get with running something in the JVM, but it's not that big of a lift, and for a lot of teams the marginal extra effort here is more than worth it because of the other benefits you get from Haskell.

> The speed-of-development vs cost-of-maintenance tradeoff of the language

Haskell is really excellent here in my experience. You can write unmaintainable code in any language, but Haskell gives you a lot of choice in how you build your application, and it makes refactoring a lot nicer than in any other language I've used. You don't get some of the nice IDE features to rename things or move code around automatically, but working in a large Haskell codebase you really do start to see ways that the language makes structural and architectural refactoring a lot easier.

> But for "what language is easy to employ and has an expansive ecosystem + tooling", I feel like you have to hand it to Java, .NET, Python, TypeScript, Go, etc...

Those are all perfectly good choices. I think what people tend to overlook is that Haskell is _also_ a perfectly good choice. Everything has tradeoffs, but Haskell isn't some terrible esoteric choice that forces you to leave everything practical on the table. It really is useful day to day as a general purpose language.

Haskell is a nightmare if you need truly seasoned industrial programmers.

Which supports the argument that "it's good for startups" which generally want to exploit young cheap talent. But as soon as your business starts needing industrial wizards you're out of luck.

The reasons/requirements to choose haskell are:

1. You already have a confident haskeller or two on your team, ideally senior

2. Your tech needs are vanilla and back-end heavy -- writing UIs in haskell is a nonstarter, and heaven help you if you're not doing vanilla web apis + postgres etc

3. You want primarily junior- to mid- talent (great for keeping burn low)

There are niche examples like compiler tech or provers where haskell is in fact dominant. It's also fantastic for threading and parallelism. Otherwise the claim that it's a good choice requires all three of the above to be true.

I still think this is an unnecessarily dire and antagonistic view of things.

> 1. You already have a confident haskeller or two on your team, ideally senior

There are really only three reasons any particular tech stack is ever selected for any project.

1. It's the standard at the company and you don't have a choice 2. You happen to be working in an extremely specialized field where one language is dominant (e.g. Haskell for compilers, python for AI) 3. Someone picks a language that they like and are confident in

I'd suggest that across the entire industry, (1) dominates by a large margin. It doesn't apply as much to startups though, because by definition startups aren't going to have a lot of existing code and won't have developed restrictive standards.

So yes, the biggest reason to choose Haskell is that you have a confident senior haskeller on the team.

> 2. Your tech needs are vanilla and back-end heavy -- writing UIs in haskell is a nonstarter, and heaven help you if you're not doing vanilla web apis + postgres etc

I agree with you about UIs. It's not a good experience and I wouldn't suggest Haskell for that. There are other specific areas where I wouldn't suggest it outside of a hobbyist project, like games or mobile development. There are still a lot of programs that need to be written and benefit from Haskell's strengths though, and sure, a lot of them are CRUDy web API things, because frankly that's most of all software that gets written.

> 3. You want primarily junior- to mid- talent (great for keeping burn low)

Haskell is perfectly viable if you want to hire a team of junior and mid level developers (so long as you have a more experienced person on the team to help them learn), but not exclusively useful in that situation. There are experienced Haskell developers out there, and there are a lot of highly skilled and experienced developers who are interested in- or at least willing to learn- haskell.

In general, I'd say that Haskell is a great choice for _most_ types of development, and can work for teams with a wide variety of experience levels. It's a real asset for hiring because there are more people who would like to work with Haskell than there are Haskell jobs out there, and in general I think Haskell still benefits from the python paradox (https://paulgraham.com/pypar.html) where people who know or are interested in it tend to be above average.

> Haskell is perfectly viable if you want to hire a team of junior and mid level developers

Looking beyond permanent hires-

In my python-based startup, we routinely offload work to contractors on an as-needed basis. Having a flexible staffing level saves us real dollars, and staffing flexibility delivers products to customers faster, which generates revenue dollars faster. From a financial perspective, our staffing flexibility delivers real, measurable economic gains.

Non-mainstream tools like Haskell break that model, effectively incurring an economic cost. Sure there are Haskell contractors, but their numbers are minuscule compared to python contractors. Given the enormous pool of python contractors, we cherry pick the very best who understand our business, our tech stack, and our work culture.

I’ve had good luck hiring contractors for Haskell related problems for much the same reason that hiring full time engineers to work with Haskell has gone well: the average quality of Haskell developers is high, and there are more people who want to work with Haskell than there are opportunities.

That probably wouldn’t scale up if you were hiring many tens or hundred of contractors. My experience with that degree of outsourcing hasn’t been positive irrespective of language though.

> CRUDy web API things, because frankly that's most of all software that gets written

If that statement is true (I couldn't say), I might argue it's incomplete, because the elephant in the room is JS/TS. Haskell-in-the-browser is in horrible shape, which means that options for tight integration with UI code are severely limited. If there really is endless work for UI-less, JS-foreign web tech then that's great for Haskell ... maybe.

Because ... look what you've done to have an incrementally better experience writing CRUD apps:

1. You've got existential bus risk in your senior haskeller, and you live or die by their quality and experience, which since there's strictly less of them, is probably off the beaten path.

2. You've chosen a stack that has a massively smaller hiring pool. The benefit of "oh they'll take less pay because of the shiny" is maybe great at first, but if you have any adoption and attendant perf problems, you'll need those senior devs. Even if they are willing to learn, they can't use the tools they know best so at a minimum you're losing momentum.

3. This is more typical of smaller langs but Haskell has it's own spin on it: you're risking not having library support for a million things when you need it. Haskell has the false comfort of doing C FFI well, but that just means that when your core integration stops being maintained, now your haskellers better be C-savvy as well.

> dire and antagonistic view of things

If that's true, it's because the promise is so much greater than vanilla apps. I loooove runtime languages and Haskell should be the best of them: better-than-average GC, incredible concurrency support, great FFI, flawless refactoring, perfect DSLs, solid apps. It makes it worth forcing programmers to learn an unusual language if you can really conquer anything, and for a bright moment in the 2010s it seemed like you could.

Now, Haskell has lost that momentum and mindshare to Rust. This is literally true with some core Haskell library maintainers straight-up defecting. There are signs in the Rust community now of slowing momentum, and for similar reasons. There might be a boom-bust cycle for advanced languages with shaky industry support, I don't know.

Haskell leadership needs to change. There needs to be a laser focus on tooling, on browser compilation toolchain, on industry adoption. Avoiding success at all costs was a clever idea for a minute (ok for 3 decades) but post 2010s, there seems to be an active desire to shut off industrial adoption to keep it safe for the tinkerers. (End rant)

Reply on news.ycombinator.com