6 ms·

Haskell in Production: Riskbook

72 points by NaeosPsy 7y ago

xvilka 7y ago
Languages like Haskell, OCaml, Rust are a perfect fit for financial industry. I would not trust my money to the Python runtime errors. It's always good to see more and more companies who realize benefits of them.
- melling 7y ago
  I've seen quite a few job postings that include Scala these days. Often it'll say Java/Scala so it's hard to say how much Scala companies are using.
- owl57 7y ago
  Are there known real-world examples of miscalculations (as opposed to crash or something like "None" printed) that would be prevented by Haskell but not Python 3? (Why "3"? Because the one thing that has bitten me is the old division operator. They were right to kill it with fire. The new "/", just like Haskell's one, always gives floats, which is good for estimates and consistently and obviously bad for money.)
  - buckminster 7y ago
    > The new "/", just like Haskell's one, always gives floats, which is good for estimates and consistently and obviously bad for money. Doesn't Haskell's operate on the Fractional type class? Which includes Rational. Or some money type you wrote yourself.
    - owl57 7y ago
      Yes. I wrongly remembered (and even checked the out-of-the-box output of ":i Fractional"!) that it doesn't include Rational, but only different flavours of floats. The original point stands: Python's Fraction defines arithmetical operators in the same sane way, and the bespoke money type is about as free as in Haskell to define them in whatever way seems useful, like throwing exceptions on adding dollars to euros. (And also throwing exceptions on adding dollars to generic ints — that one would be a compile-time error in Haskell, which is of course a good thing. Is this not only a good thing but a critical one in financial context?)
  - jolmg 7y ago
    > (as opposed to crash or something like "None" printed) Stuff like that could also cause data corruption. I don't think xvilka was referring to just miscalculations from less strict typing around numbers. Also, buckminster is right about /. ghci> :i (/) class Num a => Fractional a where (/) :: a -> a -> a ... ghci> :m + Data.Ratio ghci> :i Fractional ... instance Integral a => Fractional (Ratio a) instance Fractional Float instance Fractional Double You can make your own Fractionals by making whatever type and defining an instance for it. Ratio, for instance, is made of a pair of integers (or rather Integrals, which could be Int, Integer, Word, or some type you make up) representing fractions. Here's a comment I did in the past about Haskell's treatment of numbers: https://news.ycombinator.com/item?id=18565234 https://news.ycombinator.com/item?id=18565234
    - owl57 7y ago
      the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me Matches my limited experience with Haskell. You get some bad bugs that you don't get in Python because all the stuff like len([1,2,3]) gives int (≡ Haskell's Integer), and 0.1 + 0.2 means the same thing every time. But I'm really interested in the opposite direction: bad bugs you get in Python but not in Haskell.
      - jolmg 7y ago
        Well, like I had responded to that comment back then, casting is very explicit in Haskell, but I think they were confusing casting with type inference. Most of the time, 0.1 + 0.2 is the same thing every time, but you do have the option of it being different types, depending on what you need.
      - tome 7y ago
        Can you explain how that leads to a bug?
        owl57 7y ago
        import qualified Data.ByteString as B import qualified Data.ByteString.Char8 as C main = do let x = 100 print (x * x) let y:_ = B.unpack (C.pack "foo") --let z = x * y return () If we uncomment that line, the output of this program changes from 10000 to 16. Yes, I learned this by triggering similar action "in the past" accidentally. Don't remember details, but that program also involved ByteStrings. The convention of explicitly type-annotating top-level declarations is there for a reason: it limits the scope of damage.
- pjmlp 7y ago
  F# seems to also be used quite a bit.
bcheung 7y ago
For people using Haskell at work, how did it happen? I'm wanting to use it at work but there is a lot of pushback and I am encouraged to use languages like Go and Python.
- msvan 7y ago
  I think it's just not gonna fly in many organizations. You need the people who are going to be working with it and maintaining it to buy into it, and you also need to convince whoever is in charge of technology choices that it's a good idea. If you are the latter yourself, then that's half the problem solved. It's probably easier to join an organization that is already positive towards it.
- exdsq 7y ago
  I work for IOHK who use Haskell for a blockchain system called Cardano. You can see the backgrounds of the Haskell team here - https://iohk.io/team/#cardano https://iohk.io/team/#cardano I've found the one general thing is a strong academic background. I joined the Haskell team as a test engineer coming from several years in software engineering (Python and C#) to learn more about Haskell and Formal Methods. Unfortunately there aren't any jobs up at the moment so I can't show the reqs, however there's a compiler engineer role that requires Haskell. https://iohk.io/en/careers/fk03jlb/functional-compiler-engineer/#main-content https://iohk.io/en/careers/fk03jlb/functional-compiler-engin...
- Floegipoky 7y ago
  Start making a list of production incidents caused by bugs that aren't possible in Haskell. Even better if you can attach a monetary cost to any of them. Find a small, relatively independent project and make the case to try it out.
- dllthomas 7y ago
  I've used Haskell (more than trivially) at two positions where I was working for someone else. The first time was at Uber, where a side project I had started in Haskell proved to be something we needed, so I spent a year building on top of that. My second time was at LeapYear, whose stack was (and I believe still is) predominantly Haskell. Both good experiences - happy to elaborate on either.
_bxg1 7y ago
> [Our product] essentially involves enabling reinsurance brokers to create risk programmes and then market them to underwriters, all within our online platform. A risk programme has a fairly complex life cycle, and we model and digitalise all of the steps that professionals in the industry would traditionally have done on paper, which is of course far less efficient and far more expensive. Sounds like an ideal use-case: complex, well-defined rules and procedures that must be modeled in a fool-proof way. I think the issue for most people who dream about using Haskell at work is that their use-case doesn't have these kinds of needs, and so the tradeoffs (hiring difficulty, third-party API support, etc.) just don't make sense.
- nextos 7y ago
  Yes, it does look like an ideal use case. I really really love Haskell, but I wonder if it's a rational decision to use it in comparison to an eager ML (OCaml, F# or SML). Much simpler languages. The amount of language extensions plus laziness make the learning curve of Haskell quite steep! Still, I love this. Keep up the good work. I think that during the 2020s we will see a lot of efforts to move software errors to compile time with fancier type systems (dependent, linear, etc). I'm betting on a slightly different approach than Haskell, which I think is too complex and will never fit all use cases. I think the best approach is to have a great language to quickly build DSLs and formal verification methods (ranging from lightweight like property-based testing or type systems to heavyweight like abstract interpretation or theorem proving). So, essentially Racket (Lisp) + lots of formal techniques in a nice package.
  - wespiser_2018 7y ago
    in the 2020s, I hope we can get learn out to make complex type systems simple to use!
melling 7y ago
"If I hadn’t measured, I probably would have forgotten that Yesod does indeed make quite heavy use of Template Haskell to generate code. The core of our application is still only a humble ~17,000 lines across 182 files — not counting some external libraries we maintain — but if you were to dump the splices generated by Template Haskell we would be looking at approximately 160,000 LOC." I like to think of a programming language like a lever: "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." - Archimedes

72 points by NaeosPsy 7y ago

Languages like Haskell, OCaml, Rust are a perfect fit for financial industry. I would not trust my money to the Python runtime errors. It's always good to see more and more companies who realize benefits of them.

melling 7y ago
I've seen quite a few job postings that include Scala these days. Often it'll say Java/Scala so it's hard to say how much Scala companies are using.
owl57 7y ago
Are there known real-world examples of miscalculations (as opposed to crash or something like "None" printed) that would be prevented by Haskell but not Python 3? (Why "3"? Because the one thing that has bitten me is the old division operator. They were right to kill it with fire. The new "/", just like Haskell's one, always gives floats, which is good for estimates and consistently and obviously bad for money.)
- buckminster 7y ago
  > The new "/", just like Haskell's one, always gives floats, which is good for estimates and consistently and obviously bad for money. Doesn't Haskell's operate on the Fractional type class? Which includes Rational. Or some money type you wrote yourself.
  - owl57 7y ago
    Yes. I wrongly remembered (and even checked the out-of-the-box output of ":i Fractional"!) that it doesn't include Rational, but only different flavours of floats. The original point stands: Python's Fraction defines arithmetical operators in the same sane way, and the bespoke money type is about as free as in Haskell to define them in whatever way seems useful, like throwing exceptions on adding dollars to euros. (And also throwing exceptions on adding dollars to generic ints — that one would be a compile-time error in Haskell, which is of course a good thing. Is this not only a good thing but a critical one in financial context?)
- jolmg 7y ago
  > (as opposed to crash or something like "None" printed) Stuff like that could also cause data corruption. I don't think xvilka was referring to just miscalculations from less strict typing around numbers. Also, buckminster is right about /. ghci> :i (/) class Num a => Fractional a where (/) :: a -> a -> a ... ghci> :m + Data.Ratio ghci> :i Fractional ... instance Integral a => Fractional (Ratio a) instance Fractional Float instance Fractional Double You can make your own Fractionals by making whatever type and defining an instance for it. Ratio, for instance, is made of a pair of integers (or rather Integrals, which could be Int, Integer, Word, or some type you make up) representing fractions. Here's a comment I did in the past about Haskell's treatment of numbers: https://news.ycombinator.com/item?id=18565234 https://news.ycombinator.com/item?id=18565234
  - owl57 7y ago
    the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me Matches my limited experience with Haskell. You get some bad bugs that you don't get in Python because all the stuff like len([1,2,3]) gives int (≡ Haskell's Integer), and 0.1 + 0.2 means the same thing every time. But I'm really interested in the opposite direction: bad bugs you get in Python but not in Haskell.
    - jolmg 7y ago
      Well, like I had responded to that comment back then, casting is very explicit in Haskell, but I think they were confusing casting with type inference. Most of the time, 0.1 + 0.2 is the same thing every time, but you do have the option of it being different types, depending on what you need.
    - tome 7y ago
      Can you explain how that leads to a bug?
      - owl57 7y ago
        import qualified Data.ByteString as B import qualified Data.ByteString.Char8 as C main = do let x = 100 print (x * x) let y:_ = B.unpack (C.pack "foo") --let z = x * y return () If we uncomment that line, the output of this program changes from 10000 to 16. Yes, I learned this by triggering similar action "in the past" accidentally. Don't remember details, but that program also involved ByteStrings. The convention of explicitly type-annotating top-level declarations is there for a reason: it limits the scope of damage.
pjmlp 7y ago
F# seems to also be used quite a bit.

bcheung 7y ago

For people using Haskell at work, how did it happen? I'm wanting to use it at work but there is a lot of pushback and I am encouraged to use languages like Go and Python.

msvan 7y ago
I think it's just not gonna fly in many organizations. You need the people who are going to be working with it and maintaining it to buy into it, and you also need to convince whoever is in charge of technology choices that it's a good idea. If you are the latter yourself, then that's half the problem solved. It's probably easier to join an organization that is already positive towards it.
exdsq 7y ago
I work for IOHK who use Haskell for a blockchain system called Cardano. You can see the backgrounds of the Haskell team here - https://iohk.io/team/#cardano https://iohk.io/team/#cardano I've found the one general thing is a strong academic background. I joined the Haskell team as a test engineer coming from several years in software engineering (Python and C#) to learn more about Haskell and Formal Methods. Unfortunately there aren't any jobs up at the moment so I can't show the reqs, however there's a compiler engineer role that requires Haskell. https://iohk.io/en/careers/fk03jlb/functional-compiler-engineer/#main-content https://iohk.io/en/careers/fk03jlb/functional-compiler-engin...
Floegipoky 7y ago
Start making a list of production incidents caused by bugs that aren't possible in Haskell. Even better if you can attach a monetary cost to any of them. Find a small, relatively independent project and make the case to try it out.
dllthomas 7y ago
I've used Haskell (more than trivially) at two positions where I was working for someone else. The first time was at Uber, where a side project I had started in Haskell proved to be something we needed, so I spent a year building on top of that. My second time was at LeapYear, whose stack was (and I believe still is) predominantly Haskell. Both good experiences - happy to elaborate on either.

_bxg1 7y ago

> [Our product] essentially involves enabling reinsurance brokers to create risk programmes and then market them to underwriters, all within our online platform. A risk programme has a fairly complex life cycle, and we model and digitalise all of the steps that professionals in the industry would traditionally have done on paper, which is of course far less efficient and far more expensive. Sounds like an ideal use-case: complex, well-defined rules and procedures that must be modeled in a fool-proof way. I think the issue for most people who dream about using Haskell at work is that their use-case doesn't have these kinds of needs, and so the tradeoffs (hiring difficulty, third-party API support, etc.) just don't make sense.

nextos 7y ago
Yes, it does look like an ideal use case. I really really love Haskell, but I wonder if it's a rational decision to use it in comparison to an eager ML (OCaml, F# or SML). Much simpler languages. The amount of language extensions plus laziness make the learning curve of Haskell quite steep! Still, I love this. Keep up the good work. I think that during the 2020s we will see a lot of efforts to move software errors to compile time with fancier type systems (dependent, linear, etc). I'm betting on a slightly different approach than Haskell, which I think is too complex and will never fit all use cases. I think the best approach is to have a great language to quickly build DSLs and formal verification methods (ranging from lightweight like property-based testing or type systems to heavyweight like abstract interpretation or theorem proving). So, essentially Racket (Lisp) + lots of formal techniques in a nice package.
- wespiser_2018 7y ago
  in the 2020s, I hope we can get learn out to make complex type systems simple to use!

melling 7y ago

"If I hadn’t measured, I probably would have forgotten that Yesod does indeed make quite heavy use of Template Haskell to generate code. The core of our application is still only a humble ~17,000 lines across 182 files — not counting some external libraries we maintain — but if you were to dump the splices generated by Template Haskell we would be looking at approximately 160,000 LOC." I like to think of a programming language like a lever: "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." - Archimedes