.png)
In this edition of our Haskell in Production series, we interview FINN.no, a Norwegian digital marketplace for classified ads. We spoke with Karsten Mevassvik, the Technical Domain Expert (Tech Lead) of the AdView team, and Torgeir Strand Henriksen, a full-time Haskell developer, about their experience with Haskell and their general approach to web development.
Interview with FINN
Could you give a brief introduction to yourselves and your company?
Karsten: You can think of FINN.no as “the eBay of Norway.” It is a digital marketplace for classified ads with a uniquely high market share. We have listings in the real estate, motor vehicles, jobs and ecommerce businesses. FINN has 500 employees, where approximately 230 are in tech. There are about thirty teams, and the AdView team is one of them. This is the only team that uses Haskell in production—most teams mainly use Java and Kotlin on the backend.
Our team handles the full stack for presenting ads on web, native apps and public APIs (AdView Domain). We also maintain the public API framework and professional advertiser profiles (Company Profile domain).
How large is the Haskell team at FINN?
Karsten: The team currently includes nine developers, a product manager, a UX and an engineering manager. One developer is dedicated to the front end, the rest is more or less full stack/backend.
Where in the stack do you use Haskell?
Karsten: Haskell is used in the backend, where applications process data updates from other services via Kafka, store the results in databases, and serve data to the frontend over HTTP.
Alongside Haskell, you also use Scala and Java. How do they all live together?
Torgeir: Since the architecture at FINN is based on microservices, and each team is responsible for their own technology stack, different technologies can coexist as long as they can communicate via Kafka. There are no shared libraries that typically would cause problems when mixing languages and runtime environments.
Karsten: Technically it’s fine, it all works on the infrastructure. The team varies, some work only on Haskell, some work on full stack, some only on the frontend. One guy does most of the old legacy stuff and some are in-between. We have three developers now that you may refer to as Haskell developers.
How did you end up putting together a Haskell team?
Karsten: The team was originally a Scala team, so there was already an interest in functional programming. About five years ago, one of the developers persuaded the team to try Haskell for a new application, an internal dashboard for the team. The experiment was a success, and Torgeir was hired four years ago as the first Haskell developer. Since then, two more developers have been hired, and we have about fifteen Haskell applications running. Even though the original evangelist has since left the company, we have made sure that one person isn’t a “single point of failure.”
Are you migrating from Scala to Haskell? Do you have some sort of end goal in mind?
Karsten: We are not actively migrating Scala applications to Haskell, because they already work, and it probably wouldn’t be worth replacing them for the sake of replacing them. New applications are written in Haskell, and if a Scala application needs replacing in the future, the replacement will likely be written in Haskell.
What’s your impression of Haskell? What do you like, what do you dislike, and what are the biggest challenges you’ve encountered?
Torgeir: What I like is the extra rigidity you get from the type system. Even in Scala, where you have libraries like ZIO that try to track effects, it’s kind of opt-in, so it doesn’t catch as many mistakes.
One problem is that the community is quite small. There are less off-the-shelf solutions, and some of the libraries we use are not 100% battle tested. Even if we report bugs, we sometimes have to fix them ourselves. In general, however, I think that the benefits of Haskell outweigh these detriments.
How often do you run into issues like the aforementioned? How prohibitive are they?
Torgeir: It doesn’t happen often. Because the company architecture isn’t changing much, once we have a solution, we keep using it as long as it does the job. One example where we had to do some extra work ourselves is with the Kafka library. The official one for JVM comes with a stream abstraction, whereas the one available for Haskell is lower level. We have to use a separate stream library and connect them together ourselves, and while that works, it wasn’t as easy to get started with as using Kafka streams directly in Java or Scala.
Karsten: In general, enterprise support in the JVM world is much more mature and extremely well-supported now. Everything from IDEs to libraries. It would be naive to assume the same level of support in tooling for other languages that do not have the same enterprise mileage. Our experience is that a team needs someone to be at the forefront and make things work so the whole team does not have to struggle with e.g. the local dev environment on a daily basis.
Do you experience any pain in upgrading to the newer versions of GHC? How fast after the release of a new version do you upgrade?
Torgeir: We use Nix to manage compiler versions and dependencies. We are not on the bleeding edge, but use the stable Nix channel. It forces us to wait for the ecosystem to mature, because the compiler is not upgraded until everything is ready. For example, we are still on the GHC 9.0, even though the latest is 9.6. In general, we haven’t haven’t had a lot of trouble with compiler upgrades. There were some small syntax changes but nothing major.
Karsten: We think it is less painful than in Scala code. That tends to be painful with Scala code, which is one of the main reasons we’re not continuing with it.
How do you approach using Haskell and Nix together? Do you use haskell.nix / flakes?
Torgeir: Currently we use plain Nix, and have a simple homemade setup. We might migrate to flakes once it’s not flagged as experimental.
Can you share your experience with Haskell Language Server? How is it working for you? Do you have any issues with it?
Torgeir: When I started working at FINN four years ago, we only had syntax highlighting, and had to manually compile to get error messages. With HLS, the situation has improved a lot since then, and while it is not as mature as, for example, Java, we’re pretty happy with it. Since we don’t have one monolithic code base, I’m not sure if resource consumption is a problem when working with big projects, but for our relatively small microservices it works well.
How do you get developers building on legacy tech (e.g. Java) to move to something newer like Haskell?
Karsten: We have experience with getting developers on legacy tech onboard with new technologies, for instance, Java to Haskell. We still have to spend time on the legacy applications. Not everyone can work on Haskell 100% of the time. The big challenge is to get enough exposure to Haskell - not just Scala and Java. Because you need to actually work on it to improve your skills. So that’s been our big challenge.
It’s a good question and a big question. In my opinion, even if the developer is not working with Haskell 100% of the time, it still makes them a better programmer. Because you see the functional side more clearly. Ah, so this is how it should be done. This is a better way to solve problems. So I will try to do this when I write Java or what not.
Also, Haskell developers are generally more experienced and better engineers. Which is not always the case with academic Java programmers. They are good in the language, but not great at design thinking and putting the product all together. But that has not been the case with our Haskell people. To put it bluntly: Having a Haskell team is an effective way of getting good developers ;)
Torgeir: Let me tell you an interesting anecdote related to that. A while ago, we were hiring for a Haskell position and a front-end position at the same time. The applications for the front-end position were mostly from junior developers fresh out of university, while the applications for the Haskell position were from experienced senior developers. Haskell seems to serve as a filter for people that are more interested.
Do you have any training programs in place for training Haskell developers?
Torgeir: We have so far only hired developers who were already experienced with functional programming, so we haven’t needed it yet. But we do have some internal show-and-tells and talks within the team and sometimes open to the rest of the organization.
To read more interviews about the use of Haskell in production, head to our interviews section. And don’t forget to follow us on Twitter to stay updated about new articles!
