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

61–70 of 167 posts

Re: Haskell in Production: Standard Chartered

#61

Post by dllthomas »

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.

If you want to hire five developers, Haskell makes that easier. If you want to hire five hundred developers, Haskell probably makes that harder, although it's not something I have experience with.

Re: Haskell in Production: Standard Chartered

#62

Post by JonChesterfield »

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…

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.

Re: Haskell in Production: Standard Chartered

#63

Post by JonChesterfield »

thesz wrote: post #60
logicchains wrote: post #50

Earlier quoted context omitted.

Nim and D both have this feature. Among more popular languages, C++20 constexpr comes close: if you see a constexpr function, you know it's a "pure" function. Although there are still some things that can't be done in constexpr functions, the list is getting smaller and smaller with every new version.

constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?

I thought STM was dead. Seems to be minimal adoption within clojure and all the hardware which tried to do it has been disabled for being broken. What makes it a particularly important example?

The C++ plan of attack probably is more syntax though. Maybe parameterise constexpr, constexpr or similar.

Re: Haskell in Production: Standard Chartered

#64

Post by ParetoOptimal »

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 about it enough times that it seems like a relevant pattern.

Most people don't disable lazy evaluation in the way I think you mean it, but they use either BangPatterns selectively or StrictData.

Maybe there's widespread usage of `-XStrict` as well I don't know about.

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

Laziness is frequently talked about as a negative, but it has big advantages in composition and code ordering like another reply talked about with regards to where bindings to enable truly top-down program design.

Re: Haskell in Production: Standard Chartered

#65

Post by ParetoOptimal »

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.

Re: Haskell in Production: Standard Chartered

#66

Post by ParetoOptimal »

aranchelk wrote: post #54
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…

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, you really are describing a concept rather that telling the computer what to do. That can lead to very clear and orderly source code.

100% agree.

> Having said that, the drawbacks are significant, performance, memory usage, and debugging can all be a real pain. The last one sucks because it affects development of all kinds of programs, not just performance critical (and challenged) ones.

I think this largely depends on domain. Then, it's not clear if the best tradeoff is to go fully strict or develop better intuition for lazy evaluation in many of those cases.

> Difficulty hiring on a small scale in my experience is complete BS

I have a theory this meme is repeated by people who don't know where to find the many functional programming candidates.

Re: Haskell in Production: Standard Chartered

#67

Post by ParetoOptimal »

JonChesterfield wrote: post #63
thesz wrote: post #60

Earlier quoted context omitted.

constexpr reduces general side effects. Can we reduce specific side effects? For one very important example, consider software transactional memory. It has general side effects in the implementation behind the scenes, but inside transaction code they are not allowed. What will C++ solution look like? stmconstexpr?

I thought STM was dead. Seems to be minimal adoption within clojure and all the hardware which tried to do it has been disabled for being broken. What makes it a particularly important example? The C++ plan of attack probably is more syntax though. Maybe parameterise constexpr, constexpr or similar.

> I thought STM was dead.

My company codebase makes generous use of STM in Haskell. STM is the first concurrency solution I reach for in Haskell and I believe it's the idiomatic thing to do.

Re: Haskell in Production: Standard Chartered

#68

Post by thesz »

nh2 wrote: post #43
thesz wrote: post #29

Earlier quoted context omitted.

It cannot. Arbitrary side effects allowed by strict-by-default language without types constraining these ruin easeness of software development provided by Haskell. When your Haskell program works and walks, add bangs and it will run. Lately I heard from my colleagues it will run even without bangs as ghc has improved.

I find that too: Purity is Haskell's fundamental killer feature. Other languages now also have quite sophisticated type systems, some of which can do specific checks beyond Haskell in certain areas (Rust's control flow analysis, TypeScript's ways to do "gradual" typing of JS), while Haskell can do more in general. But only in Haskell can I look at a function's type and know it doesn't do any IO. In development and pr…

I used to entertain myself embedding various languages into Haskell, mostly hardware description related.

Usually, one goes with a static parameterization of a monad. But [1] shows that it is possible to have a dynamic parameterization, where underlying types of a state can change.

[1] http://blog.sigfpe.com/2009/02/beyond-monads.html

This means that we can control state types and, borrowing from ST monad, we can control introduction of resources and their use. If certain free type variable is in state, we can use associated resource. Deletion of resource is a deletion of free variable from a state parameterization.

All this is from 2009 or so.

The borrow checker of Rust is a library in Haskell, if you patient enough.

The purity of Haskell made many these libraries possible, exactly because we can control different side effects.

Re: Haskell in Production: Standard Chartered

#69

Post by ParetoOptimal »

Pirate-of-SV wrote: post #26
tildeheimat wrote: post #24

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

Writing parsers and tokenizers probably.

That's what it's best for, but personally I use it for everything. If I ever get into low-level code I'll probably use Rust though.

You can confirm that parsers/tokenizers is ranked "best in class" here though:

https://github.com/Gabriella439/post-rfc/blob/main/sotu.md

Post reply on HN