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

31–40 of 167 posts

Re: Haskell in Production: Standard Chartered

#31

Post by kerkeslager »

thesz wrote: post #25
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…

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.

That's objectively incorrect.

Re: Haskell in Production: Standard Chartered

#32

Post by rebeccaskinner »

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…

Hiring doesn’t really seem to be a problem for Haskell teams in my experience. Onboarding can be a little slower, but there are a lot of developers out there who want to work with Haskell. If anything, I would consider Haskell a hiring advantage.

Re: Haskell in Production: Standard Chartered

#33

Post by tome »

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.

It was written to replace an existing functional DSL called "Lambda", and to target Lambda's runtime.

Re: Haskell in Production: Standard Chartered

#34

Post by irmgardweber »

unhammer wrote: post #30
tildeheimat wrote: post #24

Should probably look into Haskell. Have absolutely no clue what's it best suited for?

Here are some stories of what it's actually used for: https://old.reddit.com/r/haskell/comments/12vhz1c/genuine_qu...

Ha! I was also curious. Thank you for sharing.

Re: Haskell in Production: Standard Chartered

#35

Post by tome »

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…

A few minor corrections

> Simon Peyton Jones is reported to have said that lazy evaluation has been kept "to keep us honest about side effects"

Rather, one of the main benefits of laziness was to force purity and thereby to instigate the development of typed effects. By contrast, the reason that laziness has been "kept" is simply that switching to strictness now would break (almost) all Haskell programs!

> lazy evaluation comes at a pretty extreme performance cost

Not really. Haskell's implementation of laziness is very high performance and the compiler can easily determine when creating thunks is not necessary. The reason that lazy evaluation leads to performance problems is that programmers don't know how to use it correctly. Whether that's the fault of the language or the programmers is up for debate.

Re: Haskell in Production: Standard Chartered

#36

Post by nh2 »

rebeccaskinner wrote: post #32
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…

Hiring doesn’t really seem to be a problem for Haskell teams in my experience. Onboarding can be a little slower, but there are a lot of developers out there who want to work with Haskell. If anything, I would consider Haskell a hiring advantage.

Hiring for Haskell has never been a problem anywhere I've seen.

I've worked profesisonally in Haskell for 9 years now.

When working as a consultancy, whenever we hired for ourselves or our clients, we got 5x more applicants than we were looking for. Of those, around 80% got a hire recommendation (unfortunately we couldn't hire them all).

When hiring 1 role for our startup, we got 40 good applicants immediately, with a single post on Reddit.

In all cases we had the luxury of picking the best-fitting among many excellent engineers.

Maybe you'll face issues if you want to hire 100 people on the spot. But most companies don't have that problem.

Re: Haskell in Production: Standard Chartered

#37

Post by [deleted] »

kerkeslager wrote: post #31
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. That's objectively incorrect.

[deleted]

Re: Haskell in Production: Standard Chartered

#38

Post by time_to_smile »

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…

Personally I think this is a strength of Haskell that many people don't really recognize and appreciate. It's a language the provides a lot of flexibility. If you want it to be a pure research language, it's happy to do that. If you need to make some sacrifices in regards to purity so you can get stuff into production, you can do that too.

As someone with a lot of time spent experimenting with programming languages, I can't think of any that can be so excellent from a research/experimentation perspective that also share the real production usage that Haskell sees. Take for example Racket, an amazing and also extremely flexible research language. It's probably easier to get started with than Haskell, but has never seen the real world usage that I've seen from Haskell.

Re: Haskell in Production: Standard Chartered

#39

Post by liendolucas »

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 that regularly program in Haskell in the industry: I want to believe that the language has nothing to do with this and is just their business logic, right?

Re: Haskell in Production: Standard Chartered

#40

Post by misja111 »

tuukkah wrote: post #15
misja111 wrote: post #7

Earlier quoted context omitted.

I'm also interested. Just guessing, but I guess it means that while they use their own (slow compiling) 'Mu' dialect for most applications, they have switched to using 'standard' GHC for their front-end apps.

Frontend here refers to the first stage of the three-stage structure of compilers, ie. the functionalities such as parsing and type checking that come before the optimization and target code generation phases: https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...

Didn't know that, thanks! But then I'm wondering how they can do parsing and type checking with GHC when they are using their own dialect, "Mu". How come GHC can parse that?
Post reply on HN