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

121–130 of 167 posts

Re: Haskell in Production: Standard Chartered

#121

Post by ParetoOptimal »

riwsky wrote: post #114
ParetoOptimal wrote: post #66

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

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

I disagree. I believe that most candidates are likely only interested in your salary, benefits, or other things not relevant to what your company does. A necessary state of affairs where worker rights and worker loyalty don't count for much in the face of the horribly named "right-to-work" laws.

Therefore a candidate that has a strong interest because of your tech stack is a positive where there wouldn't otherwise be one.

Re: Haskell in Production: Standard Chartered

#122

Post by ParetoOptimal »

whateveracct wrote: post #83
ParetoOptimal wrote: post #64

Earlier quoted context omitted.

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

> hah this is in many ways indirect proof that laziness-by-default is improving performance.

I believe this is the case, but the times it saves you are invisble.

The occurences where it bites you though are very visible and made out to be a much bigger deal than they usually are.

Re: Haskell in Production: Standard Chartered

#123

Post by ParetoOptimal »

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.

> In production Haskell you need to combine monads using e.g. monad transformers

In some workplaces, yes. However it's pretty tenable to use https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_c... with no or few additional monads.

Alternatively, you can have just a few people that understand how to compose Monads and many others writing code within them.

I'm not sure if I think it's a best practice by any means, but it's a pattern I've seen that avoids having to include monad transformers in onboarding.

Re: Haskell in Production: Standard Chartered

#124

Post by ParetoOptimal »

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.

This makes me wonder if this affects how code is typically written. Is it very elm like? Is composition more difficult? Is it very monomorphic?

Re: Haskell in Production: Standard Chartered

#125

Post by eru »

mark_l_watson wrote: post #14

Interesting interview. I applied for a Haskell job at Standard Charter in Singapore about eight years ago. I didn’t really expect to get the job because the only Haskell experience I had was my own Haskell projects and I had written a short book on Haskell. The guy interviewing me and reviewing my take home programming test had done a PhD studying aspects of Haskell. It was an interesting experience for me.

I worked in that team from 2012 to 2014. I don't have any degree and didn't publish any books.

Perhaps they made the interviews more difficult since, or you got unlucky?

Re: Haskell in Production: Standard Chartered

#126

Post by ParetoOptimal »

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.

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

There are ways to write quick n dirty Haskell. Actually a super-power of Haskell is how easy it is to refactor from "quick n dirty" to "reasonable quality" without introducing defects.

Re: Haskell in Production: Standard Chartered

#127

Post by ParetoOptimal »

grumpyprole wrote: post #111
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.

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

Re: Haskell in Production: Standard Chartered

#128

Post by ParetoOptimal »

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.

Also a much simpler alternative in my opinion to monad transformers is effectful:

https://github.com/haskell-effectful/effectful

Here's a talk on it:

https://www.youtube.com/watch?v=BUoYKBLOOrE

Re: Haskell in Production: Standard Chartered

#129

Post by ParetoOptimal »

hardwaresofton wrote: post #99
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 en…

Rust is good, but writing the experience writing Rust isn't like the experience writing Haskell.

Here is a good post on it:

https://serokell.io/blog/rust-vs-haskell

Re: Haskell in Production: Standard Chartered

#130

Post by aranchelk »

riwsky wrote: post #114
ParetoOptimal wrote: post #66

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

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 to incorporate their interests into their work and align it with the company’s needs. Build rapport and treat them with respect, so when you must ask them to do tasks that don’t align with their long term goals they won’t resent you.

If you can use your tech stack to get desirable talent in the door, that’s excellent. Now it’s your job to retain them, keep them productive and happy.

Regarding your second statement, every job ad I’ve ever seen for software engineering contains a list of preferable languages and libraries, and I’ve never doubted that all things being equal, preference would be given to candidates with greater familiarity in that stack. Should it ever the primary criterion for hiring? Probably not.

Post reply on HN