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

81–90 of 167 posts

Re: Haskell in Production: Standard Chartered

#81

Post by jsbg »

ParetoOptimal wrote: post #65
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…

> monadic complexity In production Haskell I've seen it's typical you only need to understand how to use the common Maybe, Either, and IO monads. Maybe... sometimes... you need to create your own. I actually think it's a bit of an anti-pattern, but this anti-pattern leads to a reality where the monadic complexity you alledge does not exist.

In production Haskell you need to combine monads using e.g. monad transformers and this is significantly more complicated than just understanding how bind works. It also requires a lot of boilerplate code and any errors there are not obvious to track down.

Re: Haskell in Production: Standard Chartered

#82

Post by whateveracct »

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…

People take advantage of laziness without even realizing it in production all the time. In fact, people often get free performance gains due to laziness all the time!

Re: Haskell in Production: Standard Chartered

#83

Post by whateveracct »

ParetoOptimal wrote: post #64
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…

> But in a production system, functional purity (no side-effects) is a means to an end, and lazy evaluation comes at a pretty extreme performance cost. In theory yes, in practice... not in my experience. Or at least, things are almost always fast enough in web backends. > Not everyone disables lazy evaluation in production Haskell, because not everyone thinks they need to for performance, but I've definitely heard ab…

> Anecdotally I can say that trying to enable `-XStrict` in production caused performance issues that prevented us from trialing it further.

hah this is in many ways indirect proof that laziness-by-default is improving performance. It may even be that a rote translation to strict (which `-XStrict` does) is causing _time_ leaks, which are actually pervasive in production strict-by-default code.

Re: Haskell in Production: Standard Chartered

#84

Post by jsbg »

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.

You can get features done very quickly in Haskell after the initial learning curve that most languages have. The type system lets you catch a lot of mistakes before runtime and in my experience things are more likely to work the first time in Haskell.

Testability does require some forethought but if your codebase always takes that into account then it's as easy as other languages.

Re: Haskell in Production: Standard Chartered

#86

Post by surement »

yodsanklai wrote: post #28
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…

Regarding hiring difficulty, some say it's a feature rather than a bug. There are always good candidates. And good engineers can learn and be proficient in any language. Haskell is certainly not harder than C++. I see some issues though. Some niche languages enthusiasts can be very picky and reluctant to work on other languages, and would pick Haskell when a simple python script would be more appropriate. People from…

> Some niche languages enthusiasts can be very picky and reluctant to work on other languages, and would pick Haskell when a simple python script would be more appropriate.

in my experience, these people also refuse to learn about any software engineering best practices as they are "for OO languages" and "not needed" in haskell

Re: Haskell in Production: Standard Chartered

#87

Post by nequo »

scns wrote: post #52
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…

> Simon Peyton Jones is reported to have said that lazy evaluation has been kept "to keep us honest about side effects", i.e., that size effects become immediately painful with pervasive lazy evaluation. IIRC he wrote or said that lazy evaluation, was a mistake in hindsight.

Do you have a source for that? From what I recall, SPJ says that the grass is always greener on the other side. So if Haskell was strict by default, some of us would be pining for a lazy version of it.

Re: Haskell in Production: Standard Chartered

#88

Post by boxed »

tuukkah wrote: post #16
boxed wrote: post #13

> Haskell in Production Does not use Haskell. Is it just me or is this... weird?

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.

Re: Haskell in Production: Standard Chartered

#89

Post by boxed »

yakshaving_jgt wrote: post #18
boxed wrote: post #13

> Haskell in Production Does not use Haskell. Is it just me or is this... weird?

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!

Re: Haskell in Production: Standard Chartered

#90

Post by twic »

mrkeen wrote: post #59
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…

Yes it's hard to imagine what all that code's doing. But I'm currently at a very small fintech, and I've got about half a million lines of code checked out. There is a lot of copy-pasted code, but I also have nowhere near all the repositories checked out.

I work on a trading desk at a financial firm. I just checked out all our applications, and they total 388444 non-comment lines of Java, 73889 of JavaScript, 13619 of Python, 9160 of C++, and some other things. The JS probably includes some vendored libraries. Also, this is just apps - we have a bunch of libraries used across our apps which will add tens or low hundreds of thousands more lines, but i have no systematic way to check them out, so i can't tell.

That's a single trading desk!

Post reply on HN