Haskell in Production: Standard Chartered

In this article of our Haskell in Production series, we interview José Pedro Magalhães from Standard Chartered – a multinational bank that has over 6 million lines of code written in their own dialect of Haskell called Mu.

Read further to learn more about how Haskell is written at Standard Chartered, Pedro’s experience using the language, and what tips Pedro would give to academics looking to transition into a Haskell developer job.

Interview with José Pedro Magalhães

Hi José Pedro! Could you give a little bit of introduction to yourself and the work you do at Standard Chartered?

My name is José Pedro Magalhães, but I generally go by Pedro. I’m the head of the Core Strats team at Standard Chartered Bank. Core Strats consists of over 40 developers using Haskell (well, actually Mu) as their main programming language. For most that is the only language they use, but a few also deal with C++, F#, or DevOps aspects.

I’ve been with Standard Chartered for over 8 years now, first in London, then in Singapore, and then back to London.

Personal card of the interviewee

Where does Standard Chartered use Haskell?

Pretty much everywhere in Financial Markets. Our core financial analytics library, Cortex, consists mostly of Mu/Haskell code (over 6.5 million lines) and forms the basis of our price and risk engine across all asset classes. It’s also pretty full-stack; we use it for everything, from server-side long-running batches handling millions of trades a day to front-end desktop graphical user interfaces.

Could you talk a bit more about the dialect of Haskell you’re using – Mu – and the reasons for its creation?

Mu was created to allow us to bridge the gap from an existing C++ runtime and a proprietary Excel scripting language to a well-known, well-specified real functional language. We also wanted to be able to serialise practically all values (including functions), which GHC did not provide.

So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter. We can seamlessly call C++ functions from Mu and vice-versa, and pure Mu functions can be used in Excel formulae via our Excel add-in. Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some Haskell libraries that rely crucially on lazy evaluation.

What has been your experience using the dialect and how does it compare to writing regular Haskell?

After a while you don’t really notice! Apart from the difference in operational semantics, as long as one is writing mostly vanilla Haskell you can’t tell the difference. We also have recursion disabled by default (simply because, unlike GHC, we have not optimised the compilation of recursive functions to avoid stack exhaustion) – but we actually don’t need it all too often, and we have all the usual recursive combinators (properly optimised) anyway.

What benefits do you see for using Haskell in banking and fintech areas?

One great advantage is static typing, which helps a lot in a large, diverse team and codebase. It’s not only software developers that use Mu at Standard Chartered; financial modellers and even some traders use it too. Purity also made it easy to integrate with Excel, which provided an avenue from something people knew (Excel) to something with many advantages (Mu).

Are there any large downsides of Haskell that you’ve encountered during your work?

Every now and then we have to explain to the enterprise technology audience why we use a niche programming language, rather than an established giant. We also sometimes need to build libraries or APIs for integration with certain technology toolchains that are often available out-of-the-box in other programming languages. But I wouldn’t qualify either of these (or any other we’ve encountered) as a “large” downside – just minor inconveniences.

We do run into some issues due to the size of our codebase and our compiler not scaling well to large programs. Tooling like Hoogle, Haddock, and HLint still works well at this scale, but, as a whole-program compiler, Mu can easily take several minutes to compile a single large application. We will circumvent those problems by switching our front-end to use GHC directly – an effort that has been running for several years and that should become usable later this year.

How would you characterize the hiring situation in Haskell currently? Are you having any issues finding qualified candidates for job positions?

Not really. We’ve never hired a large (i.e. more than 10) number of developers at one single time, and the market for Haskell programmers has grown a lot in the past ten years. I never get many candidates for my roles, but I almost always get a few good candidates. And having too many candidates can be a problem too! I have heard of people worrying about how to sift through 500 applicants for a Java dev role – I never have that problem.

Does Standard Chartered have an in-house training program for upskilling Haskell developers?

For training absolute beginners in Haskell we typically engage an external training partner. At the intermediate and advanced levels, we have a number of in-house resources, ranging from written materials to regularly scheduled tech talks (together with their video archives).

What direction do you see for Haskell in the banking & FinTech areas in the next 10 years?

Being realistic, I think we can only expect a modest increase in the penetration of Haskell in those industries. We (as a community) have shown that you can use Haskell without fear in large industrial settings, but more mainstream programming languages have a large momentum that is hard to break through.

Is there any other language that you think could be better in this sphere than Haskell? If so, why?

No, I don’t think so – not only in this sphere but also almost any other! There are some specialised domains for which you might want to use a specialised language, but as far as general-purpose programming languages are concerned, I do not think there is currently a better option than Haskell. I do realise this is not a widely shared opinion… but it is my strong conviction.

Before starting work at Standard Chartered, you were working as a postdoctoral research assistant at the University of Oxford. Do you think your academic CS experience has given you any advantages when compared to other Haskell developers?

Yes, I think academia helped. Apart from the obvious general exposure to Haskell and functional programming, it gave me experience in communicating complex ideas to a larger audience, both in written and spoken form. This is an extremely important skill to have.

What tips would you give to people from academia that want to transition to a developer position in the industry?

Narrowing it down to two things:

  1. If you’re considering switching to industry, try to pivot your research to something of an applied nature. You’ll probably have a harder time during CV review and job interviews if all your work is theoretical (e.g. type systems without an accompanying implementation in a practical programming language, category theory). There’s nothing wrong with those research subjects – but I think it’s easier to switch to industry if all your papers come with a working implementation, for example.
  2. Try to have a public portfolio with your code contributions available online. Outside of the companies that perform research in an industrial setting, the number of ICFP papers you published will not matter as much as the Haskell code you wrote and can show.

We hope you enjoyed our interview with Pedro!

To learn more about Haskell/Mu at Standard Chartered, you can watch Marten Agren’s talk from HIW 2021.

If you would like to read more interviews like this, you’re welcome to visit our interview section and follow us on Twitter.

Haskell courses by Serokell
More from Serokell
Functional Futures: Carp with Erik Svedäng thumbnailFunctional Futures: Carp with Erik Svedäng thumbnail
A Brief Look at Untyped Lambda CalculusA Brief Look at Untyped Lambda Calculus
Optimizing K FrameworkOptimizing K Framework