Haskell in Production: Verity

In this edition of our Haskell in Production series, we interview developers from Verity – a company that provides integrated solutions for modern asset management.

Questions in this article were answered jointly by Dima Rogozin, VP of Engineering at Verity, and Arsani Gaied and Tim McIver who are senior Haskell developers at the company.

Read further to learn why they use Haskell and what has been their experience so far.

Interview with Verity

Could you give our readers a brief introduction to Verity?

Verity is the new brand for the merger of two companies, InsiderScore and MackeyRMS. MackeyRMS was rebranded to VerityRMS, but it is essentially the same product. RMS stands for Research Management Software, which helps financial analysts and investment firms to organize and keep on top of their financial market research.

Where in your stack do you use Haskell?

About 95% of our back-end code consists of Haskell projects. Recently we have been experimenting with server-side rendering of some front-end components using Htmx, and so far so good!

Why did you choose Haskell for the project?

Our application was initially written in Ruby on Rails. The original developer had reached a point where new features regularly introduced bugs and performance issues, so he decided to try Haskell because of the relative safety of refactoring, the better performance, and better ability to reason about code. The strategy was to shell out from Rails to unix-style command pipelines, with custom Haskell console applications for the heavy lifting. It was a bold decision that served us well over the years. The Haskell bits grew in number. We were also splitting the system up into microservices such that the majority of them are written in Haskell. The decision to use Haskell on the back-end also affected the front-end. Having seen the benefits, our front-end code was slowly converted from AngularJS to ELM.

Are there any specific qualities of Haskell that make it valuable for creating asset and investment management solutions?

Given how Haskell was progressively introduced into our product, we have seen various benefits as the product became increasingly more mature.

For example:

• In the beginning, when the code was mostly Ruby on Rails and we used Haskell for a few unix-style pipeline programs, it was incredibly easy to write command-line argument parsers using optparse-applicative. We still have some of those legacy executables today.

• We have our own search DSL, and when we moved more towards a microservices architecture, Servant was around to help us build a correct-by-construction type-level API.

Haskell has great qualities that make it valuable for creating any type of application.

Qualities of Haskell that we like are:

• Most errors are revealed at compile-time rather than run-time.

• Data is correct-by-construction, related to ”making invalid data unrepresentable”. This allows for better domain modeling which comes in handy quite often.

• Refactorability: refactoring is easy by simply following compiler warnings and errors.

Did you run into any downsides of Haskell while using it? If so, could you describe those?

• We have had space leaks, most notably in HTML parsing and transformation using HXT, such that we decided to revert to simpler hand-rolled search-and-replace. We started opting for strict code where it makes sense, and enabling ghc-extensions like StrictData.

• There are some fragments of code written during a moment of excitement over arrows or lenses that now take some effort to understand.

• Dealing with many separate repositories on GitHub with an increasing number of interdependencies has become a nuisance, so we’ve started an effort to consolidate. Haskell makes that effort notably easy. The difficulty is in coming up with a module structure that makes sense, and dealing with longer compilation times.

• We experience some downsides of code written in past years when we were less experienced.

• We are a curious bunch, and Haskell offers a lot of shiny things to play with. As a result, we do not have a ”standard” way of doing things. For example, one of our projects uses Polysemy as an effect system, a few others are written in an MTL style with monad transformers, and most other projects are simply running in a ReaderT IO monad. This is neither good nor bad, and it allows us to explore new and possibly better ways of doing things. On one hand, it’s nice to have the freedom to try new ways of doing things; on the other, you’ll need to learn the particular technique used in a project and it could require a non-trivial investment.

• This last point becomes a particularly hard issue to deal with for any newcomer to the codebase, because it is not immediately clear which examples to follow, or what approach is best for a given task.

Could you list some Haskell libraries that your team found very useful while working at Verity and that you would like to feature?

• In most of our projects, we disable the implicit Prelude, and we use an alternative like Protolude or Relude. It really helps with reducing the number of imports, and avoiding partial functions.

• We use Servant in most of our web services as well. We also wrote our own authentication libraries on top of it, which we found really helpful. We also leverage OpenAPI3 (or Swagger) to auto-generate API specifications and documentation for our services.

• Of course, there are the libraries that are specific to our stack. For example, Mysql for mysql DB, Hedis for redis, Sphinx, Bloodhound for ElasticSearch, etc. Sometimes those depen dencies are not maintained, so we have to fork and implement or fix what is missing.

• Other than that, we use the regular ”bread-and-butter” libraries like Aeson, MySQL, Bytestring, Text, etc.

What kind of an effect system do you use: RIO, mtl, fused-effects, Polysemy, or something else?

In the beginning, we were strong advocates of ”boring Haskell”, writing as many pure functions as we could, and using IO where we had to. Eventually, we gained more experience, and we started learning more techniques, mostly out of necessity to be able to use some of the libraries out there. As mentioned above, we use a custom app monad (ReaderT env IO) in most projects, Polysemy in one and MTL in a few of the newer ones. One of our team members is a proponent of MTL style and is pushing for it to be used more. But all in all, as opinionated as Haskell developers can get, we as a team always welcome learning new techniques. For example, we had a good experience with Polysemy, but it seems that the consensus is that we won’t use it in any future projects due to its high barrier to entry.

Has your team run into any hiring difficulties when hiring Haskell developers?

No, Not really. Haskell job openings have always attracted a good number of high quality candidates, and the hiring process has usually been pleasant. We give the candidate a little problem to work on for a few days to solve in Haskell. This gives us an overview of how they work, their knowledge and techniques, and how they structure their code. This process has served us well so far, and we now have a small crew of people with a good understanding of working in Haskell and who work well together.

Do you have any in-house training programs to teach or upskill Haskell developers?

Nothing formal, but we do have a #haskell Slack channel where we share useful tidbits that we discover or ask questions. We also occasionally do Lunch-and-Learns where one of the developers will talk about some aspect of Haskell (or general software development) that they like and would like to promote. We also have a library of several company Haskell books, but we also found blog posts to be just as useful, although those are harder to find. Lately, a few companies have started producing Haskell videos on a lot of useful topics here and there, and we are really grateful for all the people who provide us with those resources. We usually have a budget for attending Haskell conferences, and we have taken advantage of that in the past.

Do you have any tips for developers that want to get a job in investment banking and/or fintech?

Few come to mind:

• First and foremost, strive to be an awesome developer! With this skill set, any industry will be eager to hire you.

• Focus on honing your soft skills. Enhance your communication and presentation abilities by taking courses on emotional intelligence.

• Familiarize yourself with the basics of the fintech industry, and understand terms such as equity, fixed income, alpha, and more.

Big thanks to people from Verity for answering our questions!

If you want to learn more about the company, you’re welcome to visit their website.

To read more interviews like these, head to our Haskell in Production section and don’t forget to subscribe to us on Twitter.