Haskell in Production: Riskbook | Hacker News Reader

Haskell in Production: Riskbook

serokell.io

72 pointsNaeosPsy22 comments

"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

> [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.

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.

in the 2020s, I hope we can get learn out to make complex type systems simple to use!

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.

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.

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.)

> 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.

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?)

> (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

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.

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.

Can you explain how that leads to a bug?

    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.

F# seems to also be used quite a bit.

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.

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.

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

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-engin...

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.

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.

I used Haskell for about eighteen months on a contract, but the project had chosen Haskell before I was brought aboard. Haskell was used to implement a novel programming language with strong guarantees of security and data integrity implemented in the type system. The language was both statically and dynamically typed, with static types checked at compile time and dynamic types supported by tagged hardware (the tagged hardware was still under development when I was working on the project).

I was in the senior leadership team of a company a while back (I was brought on to build a software team from scratch). I worked with the other execs to ask the question "what culture do you want in your software development team; what will be compatible with the rest of the company culture?"

Some of the options we discussed...

- Is your plan to sell the company in a year or two? Then you will probably write a lot of throwaway code, and speed of development of basic stuff is most important. If you want this, I'll hire you a team of Python or NodeJS or Ruby programmers.

- Is your plan to have software that supports your company over the long term, but the goal of the software itself is more around cost savings? Is the software development team going to be a cost centre? If so, you will end up with a revolving door of programmers coming in for short periods of time to work on it? If you want this, I will hire a team of Java or Go or C# programmers.

- Do you want to build very technically complicated software as a differentiation strategy? Then you will be looking at a team of very smart software developers who love their craft with a passion that will be a bit foreign to non-technical staff. If you want this, I'll hire a team of Haskell / Lisp / Ocaml / F# programmers.

At the time, the rest of the leadership team wanted the last option, so that's the software team we built. As far as I remember it worked quite well, I remember that there was only one significant bug that made it into production.

Reply on news.ycombinator.com