Before I answer, I need to emphasize that we didn’t convert any Python code to Haskell; broadly rewriting would not be pragmatic for us because:
- Our current Python codebase works fine in many cases;
- We aren’t ready to spend time/money training devs to learn Haskell;
What we’ve done is expanded the business into a new area where there is <10% overlap with our current business. I work for a proprietary trading firm, so concretely this means that we’re preparing to trade entirely new products where the code path will be >90% Haskell. This is done by a 2-person team part-time for now (this work often gets de-prioritized in favor of more pressing matters).
Such green-field projects are a much easier avenue to start using a different language because new code needs to be written anyways.
As an aside, I am under no illusion that the entirety of our trading operations will switch to Haskell in my lifetime; the cost-benefit analysis just doesn’t make sense:
- All products we’re trading right now have lax latency requirements (many of our competitors actually still trade manually!), and so there’s no tangible performance benefit to switching from Python to Haskell;
- Our current trading operations are acceptably stable, such that the opportunity cost of software failure is probably less than the cost of training devs to learn Haskell + a wholesale rewrite.
Now to your questions:
Python is notoriously anti-functional, so has it been hard training Pythonistas in an FP idiom?
We haven’t started training new devs yet. However, after discussing this possibility at informal events with my colleagues, I encountered a strong resistance in many of them to change from the typical object-oriented Python. I get it; I can’t expect everyone to be comfortable investing work-time into an unfamiliar programming paradigm, when programming is just a job for most people. I would estimate that only about 1/5 of devs would be interested to be trained.
Pragmatically, I will look for a different type of candidate in future hiring situations – prioritizing people with ( knowledge of Python ) AND ( (interest in learning Haskell) OR (at least basic knowledge of Haskell) ).
You’ve mentioned where things have gone right, but where have things gone wrong?
Apart from the silly memory leak I mentioned, nothing went wrong per se. One of the additional challenges with respect to Python was that we needed time-series data structures that weren’t readily available off of Hackage, so we had to build our own library (to be released officially in the next few months, probably after a community RFC). In general, one of the drawbacks of literally any programming language vs. Python is the breadth of the ecosystem. On the quantitative research side of the business (i.e. stats and machine learning), you can be sure that we’ll be using Python for years to come, simply due to the ecosystem.
Within your start-up experience, what’s Haskell’s key selling point for a sector wherein 67-85% of firms fail within 5 years?
If I had to summarize to a single key selling point, it would be “ease of refactoring”, or in business-speak, “high iteration velocity”. Startups trying to build a minimum viable product, or achieving product-market fit, or expanding to new lines of business (like us) are working with fuzzy requirements and many unknowns. In this context, the ability to adapt to changes in requirements quickly is worth key.
I’ll be sure to write a postpartum blog post once the system is live (probably by the start of 2024).
Sounds a bit like a rorschach test…