Links to profiles, and various projects referenced, are at the bottom of the page, to keep them together.
I'm speaking with Syed Jafri from Caribou and Mike Garrett (at the time of the interview Caribou; now Spotify). Syed was a subscriber of Scala Algorithms and found it because he was looking for resources on functional algorithms with Scala. After finding out that he and his manager Mike managed to advocate for Haskell at their firm, I was intrigued and they accepted my invitation for an interview. Caribou, based in Washington DC, specializes in handling the process for car refinancing in the US.
We will go through the speakers' backgrounds, decisions, tech stack, as well as their thoughts on Haskell and its future.
Syed has a background in computer science, particularly in compilers. His career started with Java, but not long into his career he got into Scala; and then joined MotoRefi when they had 5 engineers - at the time they were doing TypeScript and Ruby, and more recently, Haskell.
Mike is an engineering manager; his first experience as a team lead at a previous company, he saw great improvements in terms of efficiency when adopting Scala, growing the FinTech team from 1 to 10, using Scala and Play frameworks. Type-safety has been fundamental to the success in this team of up to 10 people. His responsibilities changed when he transitioned to engineering management and has been heading the insurance team for 8 people at Caribou.
In this interview we will discuss their unique approach to advocating for Haskell.
Background
William: Why you choose to advocate for Haskell in your company/team?
Mike & Syed: hiring is a key issue when growing a tech company: you are looking for people who understand your tech stack and also are higher quality engineers. At the time the company had a Ruby (Ruby on Rails) + TypeScript (FP style) stack, receiving enough candidates for barely 1-2 interviews per week, and rejecting most of them, despite them qualifying on paper. The initial decision to use Ruby was based on getting an MVP running quickly to secure the first round of funding. However, refactoring and scaling up was a big challenge in this stack.
Syed raised to Mike that there may be a better case in hiring if they were to use Haskell as it has a different pool of candidates; and contrary to conventional thinking, a larger pool (relative to supply). This is because there are not that many Haskell positions, but many talented engineers keen to do Haskell - in proportion to Ruby. Paul Graham talks about The Python Paradox which applies here.
Convinced, we made an argument to our CTO on the basis of the quality of candidates; fortunately the CTO also had a good experience with type-safe languages in the past, so it made sense to give it a go. Soon enough, we conducted a āpainted door testā, creating a Haskell job description, and began receiving tons of strong applicants.
William: Why did you choose Haskell over Scala, given your experience?
Syed: The problem didnāt really require a specific tech stack so there was flexibility to choose. We would have been able to build the same thing in Scala almost as well. However, when I try to accomplish the same task in Scala as I would in Haskell itās possible but maybe with more boilerplate or it feels a bit idiosyncratic. The biggest problems to me is that it feels that there are so many styles of writing Scala and interactions with everything else built on the JVM (Java libraries throwing NPEs).
How they convinced the teams; and the results
Syed: I want to discuss how we were able to convinced the leadership. We connected with the Haskell Foundation, who help with industry adoption of Haskell. They generously offered us support wherever we may face show-stoppers. Combined with the fact that it is sponsored by companies like Meta and GitHub, just further added to the argument. We got many more candidates - and hired 4 engineers very quickly. (2022 September update: the team is now at 10 engineers and expanded to cover 2 more teams: Insurance and Integrations!)
Mike: Getting many more candidates? Was more like a flood of candidates. We got many who had not done Haskell professionally, but wanted to: some that did Ruby, some that did JavaScript, and even some who wrote large libraries like GraphQL, and previosly done F# or Scala.
Syed: Compared to the Ruby side, we had a lot less competition from other companies. Applicants wanted this job specifically. It has been their dream to work with Haskell. You would not get that kind of reaction otherwise - people from big tech applying to a small company.
Mike: Indeed, people from well-known organizations were very interested; the tech ecosystem and things that you don't need those levels of sign-offs, and being able to move quickly. Drawing people from all different parts of the place. Imagine like Scala was in 2011-2013, when everyone would jump on the opportunity to try it; although Haskell is not new, right now it has the same energy that Scala had around 10 years ago.
Their architecture
William: How big is the proportion of Haskell?
Mike: We started in September, now have a full team, and 5 developers, and a product manager. The application built so far is an event-driven application that deals with event sourcing patterns, and is already deployed to production. It's representing a portion of the company's income. End of 2021, was the goal, to get it launched. 2022 was to turn Insurance into an equal part into the refinance business, going for 50-50.
Syed: We have multiple microservices, our team has written an extraordinary amount of code, and I haven't felt more confident in the quality of the code we have been writing. I can refactor the code without worrying as much, compared to Ruby & TypeScript.
In Haskell, one of the pluses, you write code that is more declarative, and we don't practice test-driven development. Recently did stress testing on our services, as everyone talks about memory leaks in haskell; did stress test on a cluster; notice that services are really performant and did not use many resources, and we did not notice memory leaks.
We practise CQRS and event sourcing, which ties into an event log using MessageDB for representing the source of truth. We append events that reflect the domain and then drive state from that.
William: What about the front-end?
Syed: We are going with TypeScript micro-frontends; and considering PureScript with in-house react component libraries for components like check-boxes, tiles, fields; the way the validation just works and visual aspects. All that has been written in JavaScript/TypeScript, so we would be able to re-use.
Mike: One microservice is REST, another is MessageDB that is on top of Postgres. Will bring Kafka in later, to handle things like multiple services connecting, ordering, you'll need a Kafka to distribute the message. It will start getting more enterprise-y soon, and you will start adding debugging and such, and will not escape from any enterprise-y logic.
Syed: We use Kubernetes, so it is also easier to ask yourself the question of why not use a different language? And so long as you've Dockerized your services you're good to go onto the Google Cloud. We also practice Simple Haskell.
William: What is Simple Haskell?
Syed: It is debatable but is useful for "marketing". Sticking to simpler features of Haskell, on-boarding time for new-joiners is better, there are fewer abstractions, and they can be productive faster. One of the arguments is it's too prescriptive, and while at times it makes sense to use the more advanced features, is it worth the extra overhead? HLint can enforce some things, and we have a style guide on our GitHub, which is a fork of someone lese's guide.
Mike: We are hiring for our Haskell role, we have one more senior role available (as of Sep 2022, hiring for a general Engineering Manager - Haskell experience not expected); we have DevOps, and a large growing team on the shared services side; looking for people with same ideas/approach that we're taking in building this team; doing what it takes to enjoy what you're doing, and not being afraid to do these things.
Syed: We're interested in people who are on the DevOps road and interested in Haskell, including Terraform, ISC and CloudFormation.
William: Would you consider generating Terraform from Haskell?
Syed: We have a shared library that's like a repository, and we have manually to update the commit --- so we want someone to build tools; or create PRs automaticaly, something like Scala Stuard, an example of that. More focus on DevOps and developer tooling related sort it.
Haskell growth
William: Would Haskell grow further at all?
Syed: Steven Dahl talks about a flywheel, and Haskell is just stuck there, and there's like a rock on the way somewhere. It'd accelerate slowly and speed up, and speed up. Maybe not in the next 5 years, or 10 years, but I believe Haskell can get more industry adoption. Maybe with more startups that are now adopting Haskell in the stage now where it will start moving.
Mike: Even if language is not being used, its concepts are being adopted more in the industry including languages like Rust. Many languages are becoming less verbose and offering functional syntax; the same thing with JavaScript (ES5, ES6 - the spread operator). When you look at it, Haskell is already super terse and there's not much to add to it. I feel it's going to be like Cobol, where people will question why you are working with such an old language, but I can still find a job in it 30 years later - so why not?
William: what sort of effort would you expect to move from Scala to Haskell?
Syed: Scala is my general programing production language, and I would use it. Going from Scala to Haskell, it was not bad; I felt that I should have done this sooner. I heard Haskell is really hard, and was even hearing this in the Scala community; but when it came to it, higher level functional programming, such as Monads and their instances, were much clearer to do in Haskell. Scala 3 maybe does this better than in Scala 2 which has a lot of boilerplate. Perhaps it would have been easier for me to learn those concepts in Haskell and apply it in Scala instead.
Mike: I think it's a good analogy. After reviewing the team's code, having that Scala experience, you can see what the language has borrowed from Haskell. Scala has to deal with Java interop. Going whole-hog to Haskell makes you a better developer in functional languages. Going from Scala to Clojure, a big tripping point is regular to infix notation. It was relatively painless coming from Scala to Haskell.
Algorithms?
Syed: Thanks for making Scala Algorithms, Scala is nice to prepare for code interviews. The norm is to use imperative algorithms, but you can drop down to imperative type code in Scala that's also memory-efficient, and also easier to do so than in Haskell. Scala's nice if you want to write both functional and imperative things.
William: Would there be demand for Haskell Algorithms?
Syed: It's hard to figure out solutions that are memory efficient and with good runtime performance in Haskell. I was trying to figure how to do Dijkstra's algorithm, or one of the solving algorithms, so was a bit harder to do. There is Haskell Typoclasspedia. I do find value giving people an intuition that might not be completely accurate. People don't like to say functors are containers, people can always refine.
William's thoughts
Syed and Mike had chosen an unusual approach in hiring: scoop up talent where there is unmet demand. Larger companies might already have their own existing standards, making it far more challenging to capture such opportunities. Smaller companies can easily out-compete larger companies by finding such opportunities and get themselves a big talent boost as a result. From my experience, those candidates who have already experimented with Scala and Haskell before even getting into it professionally stand a high chance of performing very well in a functional programming role.