Hacker News Reader

Comment by pphysch | Hacker News Reader

Two non-surprises here:

> We currently have exactly two backend engineers. A single Haskell engineer can support a 2:3+:1 data:FE:BE developer ratio and still have free BE time.

1) That they have 1-2 Haskell developers.

2) That backend is very straightforward once you separate it from data engineering and frontend, because you don't have to deal with hardware or wetware (pesky "side effects") like those other poor sods. This applies to virtually any popular backend language.

Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their real world utility beyond that.

View on HN

Evidence does not remain scant. For instance - ever used Starbucks Rewards? Congrats, you used Haskell software built by more than "two buddies." Ever shop at Target? Congrats, the inventory was likely in the store to fulfill your demand in part thanks to Haskell software built by a team.

However, a large engineer org that brings in senior non-Haskeller engineers/managers/leadership is bound to run into political troubles imo. Those types tend to blame Haskell and use it as an excuse for rewriting and re-orging - hence giving them newfound power. This isn't FUD or a strawman. This is observed behavior of many "respected" "old heads" I've had to work with/for.

That's just my experience from 3 different companies lol :) You can build software at any scale with Haskell - you just have to actually like and want to use Haskell for its cultural and technical benefits. Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out. That's just facts.

> Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out.

It’s a lazy language so estimating real world performance is hard. It has a slow compiler and a very shallow pool of talents. You don’t really need to be a complainer to think that removing it from your organisation code base is a step in the right direction if you are not an Haskell shop. I would do the same with Ocaml despite liking Ocaml.

> I would do the same with Ocaml despite liking Ocaml.

Ah yes, the language that's so famously bad at performance that its only noteworthy usage in industry is... a trading firm that needs to be able to handle data in microseconds to make money. If only they had chosen better.

The key point is the shallow pool of talents. JaneStreet definitely qualify as an Ocaml shop if you didn’t notice. It is an awesome language but I would never use it in a company which is not purely banking on it.

If you hire remote, the Haskell job market has plenty of good engineers ime.

* For most real world use, laziness and performance don't even matter. That's definitely not a good reason. If you're an engineering leader and that's your argument for moving off Haskell for, say, a backend system..then you're either being disingenuous or are a bad decision maker.

* The full compiles can be slow, but incremental compilation with ghci and cabal is never so awful in practice. And I've worked on some big projects.

* I don't think the talent pool is especially shallow. I've never had trouble hiring Haskellers or finding a job as a Haskeller. If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture), it's even easier. I built some projects entirely with teams of new Haskellers. Went great.

> If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture)

So, first you have to hire quite senior Haskell engineers, and then at one point switch them to tracking Haskell to new hires.

There aren't many companies who are willing to do that, and for a good reason.

Training new hires in Haskell isn't a full-time job. Nor one only doable by senior engineers. I've had interns teaching interns, juniors teaching juniors, etc.

Only prerequisite is a good attitude. If you start bean counting, you've already lost. If you think this level of software engineering cost optimization is necessary, you're just making your workplace worse.

> I've had interns teaching interns, juniors teaching juniors

If those interns and juniors came to you knot knowing Haskell, then this is a very bad way of teaching people. You end up with bad, non-idiomatic code, poorly understood concepts etc.

> If you start bean counting

It's not bean counting.

We ended up with plenty of idiomatic code. They came in with 0 FP knowledge.

Turns out you can learn the ropes & values in a couple months tops. Then you can learn with anyone and grow together.

All the things you fear are barely consequential in practice in Haskell. All those things - who cares? What's the worst that can happen? The language puts such a high floor on the code it's okay. The main mistakes these newbies can make are stuff about database & distributed system design - orthogonal to Haskell and something they should be mentored on anyways.

> Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their real world utility beyond that.

We (Mercury) have 60 backend engineers working on a monolithic Haskell backend. So at least there is one counterpoint to your hypothesis.

What does your onboarding process look like for Haskell engineers? Ballpark time-to-first-master-commit for new hires?

I'm another Mercury employee. When I joined there wasn't much of a specific onboarding process at all, beyond being given a few simple tickets to work on and pointed to some documentation.

I had written a very small amount of Haskell before, but IIRC correctly I think I made my first commit only a few weeks after joining. In general even people without an existing strong FP background seemed to become productive pretty quickly.

First they said that functional programming is only used for toy/proof of concept/academic things. And that’s fine, to the extent that that is true. There is a sort of real world/academenia dichotomy.

But now you’re deriding functional programming because it is used on... a regular old boring backend. Used to power a non-FP-related domain (to dismiss the “I used FP to implement another FP language” critique...). On an ostensibly real-world application. And you contrast this backend with “real world utility”...

This is quite confusing.

> Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their utility beyond that.

Evidence is abundant if you look for it. FB, Microsoft, and Standard Chartered all have active internal haskell projects.

Like all evidence, it is actually easy to find both sides. Notably, I have yet to come across a project in clojure, Haskel, or scala that wasn't abandoned as soon as the major advocate for that language left the group.

Sad in the cases where it was a well done project. Frustrating when it was bursting at the seams.

The main reason for that phenomenon is it's more personally advantageous to rewrite than to learn Haskell and extend what's there.

Haskell advocate quits? Blame them for selfishly using a toy language (they're gone anyways - who is gonna disagree?), and save the day by spending a long time reimplementing an MVP subset of what they already did. Congrats - you're a hero! The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code.

I've seen this happen multiple times. For shame - and yes people did get promotions for it. Pathetic.

This sounds like a good thing to me actually. If your company's primary language is X and you only have one enthusiast for Haskell (or any other such language), it's a bad idea to let them build critical components in their pet language. It's worth longer time for a rewrite and maybe fewer features if you can now count on anybody in the company being able to start working on it fast, instead of having to learn a whole new language and ecosystem first. It might even be less work to learn that language, but that work has to be repeated anytime somebody new needs to touch the code.

If you wanna have a supported component in some new language, you need higher-level commitment to keeping a reasonable size bench of developers who know that language at various skill levels. Of course unless you're a rather big company, maintaining hiring and training pipelines for multiple languages can be quite inefficient.

The main problem in my experience is the initial engineering team that builds the MVP is very into Haskell, and then as the team/org/company grows, they bring in outside leadership.

Outside leadership doesn't embrace Haskell (they don't know it), so they see it as a threat instead of as something to value. So then the Haskellers bleed (either due to the culture clash or due to the leadership intentionally hiring against Haskell. I saw a VPE literally say that "wanting to work in Haskell" as a motivation is a "red flag"!) and now you have a Haskell project but no Haskellers.

It wasn't Haskell's fault. But it'll take the blame by the boneheads.

Main problem that I have seen, is that new programmers jump on a lot of the higher level abstractions, mainly just because they can. It winds up obscuring more than it helps. Worse, it often locks them in to particular abstractions that aren't a good direction for where things are going.

Juniors write bad code in all languages. Why is Haskell's version of this so much worse?

My claim wasn't that the Haskell version is worse. Just that it isn't some super power that is free from this problem.

It does mitigate the problem. The worst Haskell mess I've seen is nothing compared to the balls of mud that can be made in less disciplined languages. They're not All the Same.

You may have just been lucky. The worst balls of mud I have inherited were in highly functional styles and systems.

Conversely, I may have just been unlucky. Would love to see studies and data.

>The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code.

But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. I am currently rebuilding an application full of intractable bugs and proprietary DSLs that was implemented in Salesforce with lots of bells and whistles that nobody wants or needs to be a simple Golang/Mysql app hosted on AWS. Yes, it is a tiny subset of the current functionality. But it solves the business case and will save millions of dollars per year in Salesforce fees while simultaneously making the user experience an order of magnitude simpler and allowing faster onboarding.

Engineers allowed to run free can often times spend an inordinate amount of time building things out that no one really asked for. Your Haskell backend was probably a thing of pure beauty from a programmers point of view. But an expensive liability to the business.

> But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win.

It was needed enough that the rewrite (which was slow) had to delay release and the legacy software had to be kept alive well past its sunset date (and plenty of people jetted by then.) Because the business had to keep the lights on!

The missing functionality at least was said to be missed by the business folks who made use of it. "If only we had feature X" definitely was said.

There wasn't anything too beautiful about the Haskell. It was mostly systems work. But incrementally evolving and improving would've definitely be cheaper long term than a rewrite .. but it does require people to learn Haskell, which seems to be a nonstarter for many. If people don't wanna, they don't wanna.

That would be the sad case. I have also seen the case where the code was impenetrable and did not at all lend itself to extension.

I've worked on a Haskell project supposedly like that. Took me a couple weeks of not complaining to improve it significantly. The trick was not closing my eyes at the sight of ugly bad code.

My problem with this, is you can replace "Haskell" with any other language in that sentence, and it still works.

Why's that a problem? It is true if any language.

But people act like Haskell can create a mess that is beyond what other languages can create. To the point where it isn't true that you can just..fix it by not complaining.

Hmmm. I can see your point that folks act like it can create a mess beyond other languages.

I agree that that is not accurate. I suspect it is more a reaction to the seeming claim that it is immune to that. For my part, my claim was meant to be that it needs an advocate. That is all.

I do not know why they other languages have in built advocacy across the board. Python, in particular, is seeing a ton of good will in ways I just don't understand.

> Notably, I have yet to come across a project in ... Haskell ... that wasn't abandoned as soon as the major advocate for that language left the group.

The Haskell OGs of Don Stewart, Roman Leshchinsky, Neil Mitchell, Lennart Augustsson and more left Standard Chartered. Haskell is now more widely used in Standard Chartered than it was when they were there!

This furthers my claim that there is evidence on both sides. Would be amazing if there was a study.

I'm pretty sure Nubank has for years and continues to rely heavily on Clojure. (to the point where they acquired Cognitect)

Right, I meant my point to be that you can find evidence on both sides. Far as I can see, language is not a predictor of success.

Having an advocate for a program is a predictor. That advocate doesn't have to be a developer.

Seems like you just haven't come across many projects then.

?? Do you have studies or collections of evidence that shows it skews in the other direction?

Yeah, myself. I have worked in multiple companies that used Scala and still do, even after the original people who introduced Scala already left.

That says nothing of the number of projects I have seen.

And note that I am not anti these languages. Just acking that there is plenty of experience on both isles.

Do any of these projects have more than 1-2 active maintainers?

None of them are individual projects, all of those companies have several projects in Haskell. Standard Chartered, for one, have their own custom implementation of Haskell and it is used by dozens of developers across different projects.

IIUC it's their own custom implementation of something a lot like Haskell, with the compiler implemented in Haskell.

It's called Mu. It's strict and has a few other quirks. There are a few different teams using it for different projects.

Source: Used to work there.

I've always been fascinated by the fact that these claims are always completely unfalsifiable.

"A lot of companies use this <non mainstream language> in internal projects but since it's internal, we can't show you".

It reminds me of "I have a girlfriend but she goes to another school".

I mean, what are those of us in this category supposed to do?

For the last 5 years I have 7 developers that have been working on internal applications in Haskell for an enterprise company that I am not able to show you due to legal reasons. We have a small open source library or two out there, but they are not even remotely representative of how deep our development iceberg really is.

Show corresponding Haskell vacancies—somebody has to maintain the code if it exists.

https://engineering.fb.com/2015/06/26/security/fighting-spam...

https://www.reddit.com/r/haskell/comments/phooqo/haskell_rol... https://www.reddit.com/r/haskell/comments/oee437/job_ad_seni... https://www.reddit.com/r/haskell/comments/nug8mw/haskell_job... https://www.reddit.com/r/haskell/comments/nn11sm/haskell_job... https://www.reddit.com/r/haskell/comments/n642ve/haskell_dev...

https://www.reddit.com/r/haskell/comments/8io3uk/job_work_on...

I've spoken to people who have been through that department at Facebook, and they report the scale of use of Haskell is wildly exaggerated.

So... an article from six years ago, and then a few open job reqs.

I've tech diligenced 200+ software companies and I've seen Haskell twice and Clojure once. The two that were using Haskell had to drop the project and rewrite because they couldn't find enough developers.

I have zero problems with the technical capabilities of functional programming languages, but it's simply not a smart decision to use them in for profit businesses writing CRUD apps. It simply doesn't make economic sense. When you get to scale and need to write <insert specific modular service that does this one thing really well> then it starts to make more sense.

So if you can find developers then it makes sense to better software in a more powerful language? That seems like not really a problem with either of those two languages.

"more powerful language"

Heh. My pickup truck has more torque than my Ferrari, but my ferrari goes to 60 much quicker. "Power" requires context, especially when it comes to programming languages.

There are languages that objectively make it easier to manage complicated things. They enforce strong guards against user errors and they are easy to refactor even in a large codebase it means you can do more things with a smaller team.

Whether you can find people to work on hard problems easily seems completely orthogonal to the language used in the same way that its also very hard to find top Java/C++ etc developers capable of handling non trivial work but we don't throw our hands up and say "Welp we'll just have to write it in python then because this problem is too hard".

Microsoft have their own functional language. Not exactly an internal protect.

Haskell is used in one "not real world" project doesn't mean it can't be used in "real world" projects. Here is an article titled 7 Useful Tools Written in Haskell: https://typeable.io/blog/2021-10-18-haskell-tools

I think it's generational.

I believe we are limited by our own experience, a lot of software is built upon the idea that problems are solved through procedural steps rather than a series of transformations.

This does not lend itself to thinking in a way that aligns nicely with functional programming.

Future generations will naturally think in ways unfathomable to you and I, and this will cause a shift in the fundamental approaches to software development.

I think it’s subjective. I learned Haskell early on in university and I’ve learned Lisps and it still feels like extra work to reason about programs or model domains in functional languages.

I believe functional programming advocates when you guys say it works better. But I only believe it works better for you. In my experience there’s a minority of people who find functional programming to be a powerful paradigm shift but for most developers functional programming either doesn’t resonate or resonates at the level of an academic exercise that helps you think better about writing code but best remains an academic exercise.

It can be extra work to reason about the performance and efficiency of functional programs, such is the case with higher level languages. But modelling the domain is far easier. I can solve difficult problems using Haskell, e.g. writing a specialist DSL compiler targeting a GPU. I'm just not smart or patient enough to solve such problems in C/C++ or Java, although I do concede that many can.

I did the same path as you.

I think that the procedural programming is much more common because of the academic and work experience of many programmers. Functional programming is a transition of the way of thinking that seems not worth it. But after I got my hands dirty, I found myself writing much more clean and consistent code in every language. I enjoyed particularly Clojure because has a good ecosystem and tools, and also take some design decisions to steer you for a more robust code. https://clojure.org/about/functional_programming#_immutable_...

I broadly agree. I actually think most people are most at home in the procedural domain, and most just write procedural code in OOP languages. Which is hard to do in an FP.

Erlang is often described as having an imperative core. It was my gateway drug for FP, I certainly found it much easier to grasp and write than any Lisp.

As did I. I went imperative languages -> Haskell (wtf) -> Clojure (wtf) -> Erlang (love it) -> Clojure (love it) -> Elixir (love it).

My two favorite languages these days are Clojure and Elixir. Currently mostly Clojure because my main side project is more amenable to Clojure's methods of concurrency than Elixir.

Last time I checked, everything is still running on von Neumann/Harvard CPUs. Did I miss a major revolution in computing?

Forgive the tangent, but your comment reminded me of item #52 on the venerable "Things to say when you're losing a technical argument" list. :)

http://web.archive.org/web/20050131033632/http://www.skirsch...

Yikes.

Yes, nowadays we have those machines, called computers (or automatic computers if you need the older name for reference), that can take software made for one architecture, no matter how unreal, and turn it into software made for another architecture.

Could you share a Haskell compiler that produces output that can execute on a real non-von Neumann/Harvard architecture?

Why would anyone have built one of those, if non-von Neumann architectures are so rare? Compilers aren't much of a weekend project. I don't get your point.

Yes

Please elaborate.

Compilers.

Which (Haskell) compilers that target actually-existing hardware do not output procedural bytecode?

That is the point.

Honestly my first thought when I saw the title “why we use Haskell” was “because you have one engineer and they like Haskell?” I suppose I was wrong. It was two.

Reply on news.ycombinator.com