Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell in Production: Standard Chartered

serokell.io

Post reply on HN
Print view View original

91–100 of 167 posts

Re: Haskell in Production: Standard Chartered

#91

Post by thesz »

foldr wrote: post #77
thesz wrote: post #25

Earlier quoted context omitted.

If you disable lazy evaluation, you would not be able to write arbitrary "where" sections, with definitions ordered as you want them, including tying-the-knot definitions, which are not exceptionally rare. So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. I also have to say that focusing on the types in the compiler development was the right thing, but what was not right is not…

>So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. True of vanilla Haskell, but from the article: > So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter... 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 crucia…

Mu was developed using Haskell, that's the point. The strict runtime and interpreter may or may not be build using Haskell, I dont't know.

As far as I know, the author of Mu is Lennart Augustsson, also author of Bluespec [1]. Bluespec compiles language that is very reminiscent of Haskell into a hardware gates. And Bluespec is relatively successful. Is there anything in the hardware gates' "evaluation model" that is related to the success of Bluespec.

Re: Haskell in Production: Standard Chartered

#92

Post by postexitus »

great_wubwub wrote: post #48
liendolucas wrote: post #39

I'm shocked, in the first paragraph they assert that they handle 6 million lines of code. Is it common for the fintech industry to have codebases of that magnitude? I'm aware that for example OSes and browsers can achieve similar sizes (if I'm not wrong certainly more) but I'd have never thought that a fintech company could approach such size. It just seems way too much... Edit: Question out of ignorance for people t…

I don't know about Standard Chartered specifically, but I remember one of the big US banks (I forget which one. JPMC or Goldman Sachs, probably - it was a while ago) telling us that they had more developers than Microsoft. Don't sleep on these finance companies, they're big development shops.

Jamie Dimon said that they have enough engineers to build their own Windows, back in 2007/2008.

Re: Haskell in Production: Standard Chartered

#93

Post by foldr »

thesz wrote: post #91
foldr wrote: post #77

Earlier quoted context omitted.

>So no one disables lazy evaluation. It is strict evaluation that is selectively enabled. True of vanilla Haskell, but from the article: > So we ended up with Mu, a whole-program compiler to a bytecode representation with a small runtime interpreter... 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 crucia…

Mu was developed using Haskell, that's the point. The strict runtime and interpreter may or may not be build using Haskell, I dont't know. As far as I know, the author of Mu is Lennart Augustsson, also author of Bluespec [1]. Bluespec compiles language that is very reminiscent of Haskell into a hardware gates. And Bluespec is relatively successful. Is there anything in the hardware gates' "evaluation model" that is r…

I mean it's a point, but it's not really the point that the article is making:

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

Re: Haskell in Production: Standard Chartered

#94

Post by yakshaving_jgt »

boxed wrote: post #89
yakshaving_jgt wrote: post #18

Earlier quoted context omitted.

Mu is essentially Haskell. It's not clear to me where you got "does not use Haskell" from.

It's quite clearly different in many important ways. Not being lazy is a pretty huge one!

Ok, but we're not quite talking about the difference between Haskell and Clojure, for example.

Re: Haskell in Production: Standard Chartered

#95

Post by tuukkah »

boxed wrote: post #88
tuukkah wrote: post #16

Earlier quoted context omitted.

Sure, it's a bit weird but not that weird as they have a huge codebase in a specific domain. Also, they still end up using a lot of Haskell code (and semantics) although they write in a thin layer of "DSL" on top of Haskell and GHC (which itself is a lot of "Haskell in production"). > Mu has a strict runtime, which makes program performance easier to analyse and predict – but prevents us from just copy-pasting some H…

From what I understood they don't use Haskell underneath at all, but they copy paste code from Haskell and sometimes have to modify it.

They say their codebase includes 400k lines of Haskell code (plus 4.5M lines of Mu). Also, they use GHC which is a huge Haskell program, and they customize it with their own extensions etc.

As they copy Haskell library code and only sometimes modify it, I would count it as Haskell code until they modify it.

Re: Haskell in Production: Standard Chartered

#96

Post by ykonstant »

mrose11 wrote: post #80

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

It makes perfect sense; non-technical users and employees with different specializations (like actuaries) use lots of Excel, especially in fintech; and if you can share function implementations verbatim between your codebase and Excel, you get higher confidence for coherence.

Re: Haskell in Production: Standard Chartered

#97

Post by justincredible »

koromak wrote: post #71

I'm just starting to learn Haskell and I honestly can't fathom how it gets written in production. Everything requires so much more consideration, which is fun and valuable in some situations, but not when you just need to get the damn thing done in time for a deadline. I'm not experienced enough to know, but it does feel like Haskell prioritizes "clever" code. Very beautiful, but hard to understand at a glance.

[dead]

Re: Haskell in Production: Standard Chartered

#98

Post by ghostwriter »

foldr wrote: post #78
slacknatcher12 wrote: post #58

Earlier quoted context omitted.

> It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. This is off-repeated, but has two interpretations. If you mean performance as in number of steps needed to reduce an expression, lazy evaluation is superior to strict evaluation. If you mean the indirection needed to access a thunk, well someone -- either the producer (strict) or the consumer (laz…

I think you're overcomplicating this. In a language with lazy evaluation, you can't know what gets evaluated without looking at the whole program (in the worst case). It's in that sense that performance becomes non-local. Here's a simple specific example. Take the Haskell expression [1..n], for some big n. There is no general answer to the question "what would be the performance implications of replacing [] with [1..…

> In a strict language, you can say (roughly at least) that replacing [] with [1..n] will add at minimum a certain number of extra CPU cycles and a certain amount of additional allocation.

It's not at minimum, it's always the worst case cost of N in strict languages, whereas the lazy setting provides you with amortized complexity.

Re: Haskell in Production: Standard Chartered

#99

Post by hardwaresofton »

kerkeslager wrote: post #17

I've talked to a lot of people using Haskell in production over the years, and one of the things I've consistently noticed is a disconnect between the Haskell features that are often touted, and the Haskell features that people use in production. This isn't always a quiet omission, like "we didn't end up using this" either. The best example is that a lot of people end up doing some significant work to disable lazy ev…

> Production users of Haskell do seem to be happy about types, years into projects, so I'd take away that types are a benefit, but I do wonder if one might get those same benefits in another language without the problems which seem to crop up with Haskell, such as laziness causing performance issues, monadic complexity, and difficulty hiring.

Rust. Rust is that language.

Rust's type system is good enough and close enough to Haskell without the footguns of other options (Java, C++, etc), with new paradigms that Haskell hasn't yet fully adopted (borrowing, etc) and consistency in build tooling, etc.

I hate to say it, but it's incredibly hard to suggest people run Haskell in production when Rust exists and you basically trade the difficulty of learning monads + mtl + ... for the difficulty of learning to live with the borrow checker.

Re: Haskell in Production: Standard Chartered

#100

Post by WJW »

mrose11 wrote: post #80

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

What's weird about that? Excel is absolutely everywhere in finance, so if you have a special programming language that you consider to be part of your secret sauce it makes sense to integrate it into excel as well.

A friend who works as a at risk manager at a major bank sometimes shares horror stories about the giant spreadsheet they have for some part of their holdings. They have disabled the "automatic recalculation" feature because it takes over 48 hours to recalculate everything. This is after running it through a special excel compiler to speed it up.

Post reply on HN