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

151–160 of 167 posts

Re: Haskell in Production: Standard Chartered

#151

Post by icrbow »

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's type system is good enough

Good enough for what?

> close enough to Haskell

Close enough for what?

> with new paradigms that Haskell hasn't yet fully adopted (borrowing, etc)

Honestly, I don't want to think about borrowing. For my gamedev/rendering tasks I have resource regions (as a library) and trust the runtime to do its thing.

Re: Haskell in Production: Standard Chartered

#152

Post by dreixel »

cosmic_quanta wrote: post #5

While Haskell jobs may appear scarce, Standard Chartered is often recruiting for Haskell devs: https://discourse.haskell.org/search?expanded=true&q=Standar...

Thanks for finding these! More directly, here's my latest jobs post: https://discourse.haskell.org/t/haskell-jobs-at-standard-cha...

Re: Haskell in Production: Standard Chartered

#153

Post by ghostwriter »

riwsky wrote: post #139
ParetoOptimal wrote: post #121

Earlier quoted context omitted.

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

I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really…

> I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people.

How is "being there for the mission and for the people" better than "being there for money and for tech stack"? The latter also has to do with people and missions, only the missions and the people are important and related to the candidate directly, and not through company owners' or hiring managers' goals (most likely motivated by prospects of monetary rewards too).

Re: Haskell in Production: Standard Chartered

#154

Post by thesz »

foldr wrote: post #149
thesz wrote: post #141

Earlier quoted context omitted.

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…

I can copy-paste some of Haskell definitions into Agda source file and vice versa. I can copy-paste some of C code into C++ source and vice versa. Given C preprocessor, some Lisp code can be moved into C or other languages.

The likeness of languages' syntaxes does not mean they are the same.

Re: Haskell in Production: Standard Chartered

#155

Post by foldr »

thesz wrote: post #154
foldr wrote: post #149

Earlier quoted context omitted.

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

I can copy-paste some of Haskell definitions into Agda source file and vice versa. I can copy-paste some of C code into C++ source and vice versa. Given C preprocessor, some Lisp code can be moved into C or other languages. The likeness of languages' syntaxes does not mean they are the same.

https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf

> Mu is a true Haskell dialect in that code written in Mu may be compiled with a Haskell compiler.

> [...]

> Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, […]

My point was that "if S&C is to count as a Haskell success story (which it's often touted as), then it's fair to point out that it's a codebase where eager evaluation is used throughout." Please note the 'if'. The article presents S&C's large Mu codebase as a Haskell success story. In this context it's perfectly fair to point out that Mu has a strict semantics.

If you want to insist that Mu is an 'entirely different' language to Haskell then that's fine. As with natural languages, there's no objective line to be drawn between 'different dialect' and 'different language'. However, anyone who holds to this view obviously cannot follow the article in presenting a large Mu codebase as an example of Haskell in production.

Re: Haskell in Production: Standard Chartered

#156

Post by thesz »

foldr wrote: post #155
thesz wrote: post #154

Earlier quoted context omitted.

I can copy-paste some of Haskell definitions into Agda source file and vice versa. I can copy-paste some of C code into C++ source and vice versa. Given C preprocessor, some Lisp code can be moved into C or other languages. The likeness of languages' syntaxes does not mean they are the same.

https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Mu is a true Haskell dialect in that code written in Mu may be compiled with a Haskell compiler. > [...] > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, […] My point was that "if S&C is to count as a Haskell success story (which it's often touted as)…

What is described in article is a subset of Haskell: "...as long as one is writing mostly vanilla Haskell you can’t tell the difference."

And then it proceeds to tell us that you can't tail recurse.

Mu is different language which uses Haskell ecosystem.

What I am interested in and what article does not tell is how big the actual Mu compiler is. I think it is in the hundreds of thousands of lines of code, 200K SLOC or more.

And it is still a big code base and it's use of Haskell is success.

Re: Haskell in Production: Standard Chartered

#157

Post by mark_l_watson »

weavie wrote: post #23
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.

Did you get the job?

No. The interviewer suggested that I get one year experience elsewhere, then reapply for the job. I started to do that, but a month into a Haskell gig, I received an offer to manage a deep learning team at Capital One, and pivoted.

Re: Haskell in Production: Standard Chartered

#158

Post by mark_l_watson »

eru wrote: post #125
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?

I just don’t think I had enough Haskell experience.

Re: Haskell in Production: Standard Chartered

#159

Post by spopejoy »

ParetoOptimal wrote: post #126
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 q…

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

I call haskell "the language of maintainable spaghetti" in this spirit. It really is incredible how types can take 99% of the risk out of refactoring.

Indeed while I miss machine refactoring tools from Java, I've seen vanishingly few bugs result from manual refactoring in haskell.

Re: Haskell in Production: Standard Chartered

#160

Post by kerkeslager »

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.

Sadly?

If a client comes to me and says one of the parts of their application was slow, and I come back to them saying I lowered the number of reductions with zero change in the wall clock time, they'll fire me, and rightly so.

Post reply on HN