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

111–120 of 167 posts

Re: Haskell in Production: Standard Chartered

#111

Post by grumpyprole »

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…

> I do wonder if one might get those same benefits in another language without the problems which seem to crop up with Haskell

Not until other languages raise their game. Nothing compares to Haskell for productivity and I've tried many different languages professionally over the years (including Haskell). But yes, reasoning about what happens operationally is the big problem.

Re: Haskell in Production: Standard Chartered

#113

Post by grumpyprole »

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.

Sounds like you just need more practice. Haskell is more expressive than most other languages and offers much more consistent and powerful abstractions. This does result in more productivity once the learning curve is overcome.

Re: Haskell in Production: Standard Chartered

#114

Post by riwsky »

ParetoOptimal wrote: post #66
aranchelk wrote: post #54

Earlier quoted context omitted.

Subtle correction: as far as I’m aware if you were to disable lazy evaluation (which you can now do via compiler pragma) on any Haskell program of significant complexity it would blow up. Common practice is to force evaluation of critical sections of code. That’s something the compiler can sometimes do for you. Laziness in Haskell is a great way to write declarative code, you really are describing a concept rather th…

> Subtle correction: as far as I’m aware if you were to disable lazy evaluation (which you can now do via compiler pragma) on any Haskell program of significant complexity it would blow up. Common practice is to force evaluation of critical sections of code. That’s something the compiler can sometimes do for you. Anecdotally I can confirm this is true. > Laziness in Haskell is a great way to write declarative code, y…

If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate.

If your company needs to find candidates primarily on the basis of their familiarity with your particular tech stack, that is probably the wrong tech stack.

Re: Haskell in Production: Standard Chartered

#115

Post by slacknatcher12 »

JonChesterfield wrote: post #62
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…

This reply neatly captures that functional programming tends to consider performance/efficiency in terms of number of reductions. Sadly other programmers tend to view it as wall clock time and the two don't correlate very well.

I just gave a list of possible meanings of what parent said. Only one of them is the numbers of reductions.

Re: Haskell in Production: Standard Chartered

#116

Post by consilient »

jsbg wrote: post #81
ParetoOptimal wrote: post #65

Earlier quoted context omitted.

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

Writing your own monad transformers is more complicated than understanding bind. Using standard ones isn't: swap out `State s a` for `MonadState s m => m a` (or whatever the relevant effects are) and put `lift` where the compiler tells you to, and you're 90% of the way there.

The other 10% is stacking the appropriate sequence of `FooBarT (BarBazT ... )` at the entry point to your program, which is admittedly pretty tedious.

Re: Haskell in Production: Standard Chartered

#117

Post by scns »

nequo wrote: post #87
scns wrote: post #52

Earlier quoted context omitted.

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

Sadly no. I think it may have been the answer in an interview to what he would have done differently with all the hindsight experience he now has.

Re: Haskell in Production: Standard Chartered

#118

Post by game_the0ry »

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'm shocked, in the first paragraph they assert that they handle 6 million lines of code.

I work at a bank.

To answer your question - yes. The consumer website for the bank I work at was 9 million lines of code (at least as of 2019). A lot of it was bad code, some of it was dead code that was never deleted.

Re: Haskell in Production: Standard Chartered

#119

Post by foldr »

ghostwriter wrote: post #98
foldr wrote: post #78

Earlier quoted context omitted.

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.

I think you might be misunderstanding what I meant by "at minimum". I'm talking about the case of replacing a [] constant in some arbitrary piece of code with something like [1..10000]. Given strict semantics you'll of course incur at least the time and space costs associated with constructing the list (that's the "at minimum" bit), but you might also incur additional costs depending on what the rest of the code does with the list. For example, it might execute some arbitrarily expensive computation if the list has more than 20 elements, or whatever.

I think you might have thought I was saying that given a strict semantics it was somehow still possible that you wouldn't necessarily incur the full time and space penalty for constructing n elements (which of course is not the case).

Re: Haskell in Production: Standard Chartered

#120

Post by foldr »

tome wrote: post #102
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 is strict because it was designed to target an existing strict runtime. That's all.

Quite possibly, but I suspect there are good reasons why the existing runtime is strict.

In any case, regardless of the underlying motivation, it is certainly an interesting fact that one of the largest commercial Haskell(ish) codebases uses a strict variant of the language.

Post reply on HN