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

141–150 of 167 posts

Re: Haskell in Production: Standard Chartered

#141

Post by thesz »

foldr wrote: post #120
tome wrote: post #102

Earlier quoted context omitted.

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.

Mu is not Haskell, it is entirely different language.

The Haskell codebase that made Mu possible is not strict.

Re: Haskell in Production: Standard Chartered

#142

Post by cuteboy19 »

grumpyprole wrote: post #110
usgroup wrote: post #27

I'm struggling to understand how possibly inventing your own language -- one not even compatible with the Haskell eco-system -- was ever a good idea in production.

Why is it any different to "bank python" used by e.g. JPMorgan or BAML? Or Google writing Dart?

I don't think they ever touched the interpreter. It's more like a huge framework on top of regular py.

Re: Haskell in Production: Standard Chartered

#143

Post by brundolf »

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…

> lazy evaluation comes at a pretty extreme performance cost

This is surprising to me. I understand it making code harder to debug because timing/ordering is less predictable, but I would expect lazy evaluation to help with performance if anything ("the code doesnt rely on a specific 'when', so the compiler/runtime are free to re-arrange stuff for optimization")

What am I missing?

Re: Haskell in Production: Standard Chartered

#144

Post by grumpyprole »

cuteboy19 wrote: post #142
grumpyprole wrote: post #110

Earlier quoted context omitted.

Why is it any different to "bank python" used by e.g. JPMorgan or BAML? Or Google writing Dart?

I don't think they ever touched the interpreter. It's more like a huge framework on top of regular py.

It's an entire fork of the Python ecosystem. So not really that much different to what we have here. Maintaining an ecosystem of libraries and tools is the hard part, not a compiler or interpreter.

Re: Haskell in Production: Standard Chartered

#145

Post by grumpyprole »

ParetoOptimal wrote: post #127
grumpyprole wrote: post #111

Earlier quoted context omitted.

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

> 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). 100% agree. > But yes, reasoning about what happens operationally is the big problem. What types of issues do you experience?

> What types of issues do you experience?

In GHC Haskell, it can be difficult to predict the lifetime of heap objects and control when objects are not shared (optimisations may or not lift terms out of a local context).

Re: Haskell in Production: Standard Chartered

#146

Post by boxed »

yakshaving_jgt wrote: post #94
boxed wrote: post #89

Earlier quoted context omitted.

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.

Sure. But it is almost the difference between Haskell and OCaml.

Re: Haskell in Production: Standard Chartered

#147

Post by kaba0 »

slacknatcher12 wrote: post #58
logicchains wrote: post #46

Earlier quoted context omitted.

>The reason that lazy evaluation leads to performance problems is that programmers don't know how to use it correctly It's because it's objectively harder to reason about performance with lazy evaluation as performance becomes non-local. You can no longer reason about a function's performance just by looking at its body, instead you have to know the nature of the inputs passed to it (whether they're thunks or materia…

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

Interesting comment, but many parts of it flew over my head. Would you by chance have some suggestions on where could I better my knowledge of Haskell internals/FP runtimes? Of course your blog has been added to my to-read list :)

I used to know Haskell to an “intermediate level”, but haven’t used it in years, but I am more familiar with “traditional” runtimes/compilers, like the JVM as a reference.

Re: Haskell in Production: Standard Chartered

#148

Post by aranchelk »

riwsky wrote: post #138
aranchelk wrote: post #130

Earlier quoted context omitted.

I’ve seen versions of the first statement several times from different users on HN, so know I’m not singling you out, but I believe this to be a deeply flawed view: It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job. Create a positive working environment. Get to know your employees and what their goals and interest are. Do your best to find ways t…

> It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job. It’s my job to do that for the right candidates . Positive working environment, caring about employee growth, long term goals—all these things you mention are extremely important, and they are what we should be competing on. If an engineer would forgo an opportunity that provides those just so…

Surely there must be some lower bound of technology after which a candidate can be completely excused for turning down a job regardless of the factors you have said should be their criteria. Examples: Perl, COBOL, or punch cards.

Re: Haskell in Production: Standard Chartered

#149

Post by foldr »

thesz wrote: post #141
foldr wrote: post #120

Earlier quoted context omitted.

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.

Mu is not Haskell, it is entirely different language. The Haskell codebase that made Mu possible is not strict.

> their own dialect of Haskell called Mu. [emphasis mine]

>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 crucially on lazy evaluation. [emphasis mine]

If Mu were an entirely different language then you wouldn't be able to copy-paste any Haskell libraries. See also e.g. here: https://www.quora.com/Why-did-Standard-Chartered-need-its-ow..., https://www.youtube.com/watch?v=hgOzYZDrXL0

Re: Haskell in Production: Standard Chartered

#150

Post by yakshaving_jgt »

boxed wrote: post #146
yakshaving_jgt wrote: post #94

Earlier quoted context omitted.

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

Sure. But it is almost the difference between Haskell and OCaml.

I suppose it's all relative. Given some selection of enabled language extensions, are you still writing Haskell? I think in the minds of most people (at least on this forum) the difference is academic. Whether a given body of work in Haskell looks like Elm, or if it's all GADTs, data kinds, and type families, they'd both be met with "Surely nobody actually uses this in production! This is ivory tower nonsense! I can't read it! It's not practical! I just want to get stuff done!" ad infinitum.
Post reply on HN