Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Joy and Agony of Haskell in Production

stephendiehl.com

Post reply on HN
Print view View original

21–30 of 94 posts

Re: The Joy and Agony of Haskell in Production

#21

Post by mbrock »

brobinson wrote: post #6
mbrock wrote: post #5

Earlier quoted context omitted.

As a big Haskell fan, the memory usage of GHC on certain modules is one reason I don't use it as much as I'd want. Several times I've had to double my swap file or increase the RAM on a VPS to compile some Haskell package, and I don't want to impose that on users of my software. Usually people don't build Haskell on their servers, just deploy binaries, but I do all my work on a VPS right now. Anyway, compiler resourc…

My only experience with compiling Haskell on a VPS involved over 100gb of swap I/O happening during a >24 hours compilation of LambaBot on a 512mb machine.

In a utilitarian sense, the pain caused by this could probably be greatly reduced with a robust system of cached binary builds. Right now we're all just compiling the same dependency trees over and over again, wasting cycles.

So since making GHC drastically more efficient is an enormous problem, maybe getting Stack/Cabal to download binary caches would be the best way to go forward.

There's a Nix build server that offers all of Stackage in binary form. That really takes a lot of pain away, at least if you're on a supported architecture (x86_64, I guess). But it's run by a volunteer individual, I think.

Of course, Debian and others have been packaging Haskell binaries forever, but I don't think most people want to deal with distribution packages for development.

I'm sure there are lots of discussions about this in other places... All I've found from my random googling is this post which is about binary sharing on the same computer:

https://www.fpcomplete.com/blog/2015/09/stack-more-binary-pa...

Re: The Joy and Agony of Haskell in Production

#22

Post by klibertp »

sklogic wrote: post #14
fsloth wrote: post #12

Earlier quoted context omitted.

"when people are ready to engineer code that lasts 1000 years" Actually, as silly as it sounds, I write most my hobby code in C++ because of this. Well, not for a thousand year span but for longevity anyway.

C++ if far too volatile. Stick to Common Lisp instead, it is a living fossil.

"Living" being the a key word here.

I was astonished when I started learning Common Lisp last year: the language, despite its warts, feels modern and convenient, and the ecosystem - SLIME, asdf & quicklisp - is impressively well designed and surprisingly nice to use.

Re: The Joy and Agony of Haskell in Production

#23

Post by akurilin »

Comments based our experience with production Haskell at Front Row:

* stack is pretty solid at multi-package builds, save everything in one single git repo for easier snapshotting. See yesod for reference

* use stack with stackage LTS unless you have a really good reason not to

* TH is nice to avoid, but you also miss out on great libraries like Persistent. Seems reasonably hard to dodge that one if you're sold on the conveniences of the yesod ecosystem

* We've been overall pretty happy with classy-prelude as Prelude replacement. Can throw off beginners at first, but is quite convenient to work with.

Re: The Joy and Agony of Haskell in Production

#24

Post by fsloth »

sklogic wrote: post #14
fsloth wrote: post #12

Earlier quoted context omitted.

"when people are ready to engineer code that lasts 1000 years" Actually, as silly as it sounds, I write most my hobby code in C++ because of this. Well, not for a thousand year span but for longevity anyway.

C++ if far too volatile. Stick to Common Lisp instead, it is a living fossil.

Thanks, but I'm not very productive in Lisp. Lisp development environments need emacs and emacs and my brains are not compatible. I've tried the 15 years to pick it up time and again but to no avail. Last time I even made a cheat sheet for myself (a link here as a proof of effort):

https://www.dropbox.com/s/ceiijwn8s31j8hv/emac_memo.svg?dl=0

Given the platform availability I'm pretty sure C++ will eventually reach the living fossil status Lisp and Fortran have.

Re: The Joy and Agony of Haskell in Production

#25

Post by dasmoth »

wereHamster wrote: post #20

I don't agree that TH is bad. It's bad for generating real code (like I wouldn't use it to generate complicated logic), but just like you don't write Eq,Show,Ord instances yourself and instead let the compiler derive them for you, you use TH to generate JSON instances. I see TH more as a extension of deriving so I can easily derive custom typeclasses than for generating real code.

This case seems to increasingly be handled by DeriveGeneric. I realise the performance isn't quite the same, but so far my experiences of GHC generics have been pretty positive.

Re: The Joy and Agony of Haskell in Production

#26

Post by javiercr »

> Haskell code tends to be of high quality by construction, but for several reasons that are only correlated; not causally linked to the technical merits of Haskell. Just by virtue of language being esoteric and having a relatively higher barrier to entry we’ll end up working with developers who would write above average code in any language.

I think this happened to Ruby for some time, not anymore probably. Maybe the next language to get the benefits of the "experienced early adopters effect" will be Elixir.

Re: The Joy and Agony of Haskell in Production

#27

Post by DanielBMarkham »

This was good. Thank you.

The part that most worried me was If we look at the history of programming, there are many portents of the future of Haskell in the C++ community, another language where no two developers (that I’ve met) agree on which subset of the language to use.

I also perked up when he talked about the difference between pipeline-paradigm coding and coding involving monadic trees.

I'd love to dive into the language, but with F# I'm happy enough that I code as little as possible and create lots of value. While I think that would be even more true in Haskell, it doesn't seem worth the switch -- yet.

Having said that, I'm definitely seeing some parallels between my own experience in F# and this author's experience in Haskell, especially the part about multiple ways to solve a problem. Are there no good books about common FP best practices? Seems like much of what you would consider a "best practice" would apply whether it's F#, OCAML, or Haskell.

Re: The Joy and Agony of Haskell in Production

#28

Post by sklogic »

fsloth wrote: post #24
sklogic wrote: post #14

Earlier quoted context omitted.

C++ if far too volatile. Stick to Common Lisp instead, it is a living fossil.

Thanks, but I'm not very productive in Lisp. Lisp development environments need emacs and emacs and my brains are not compatible. I've tried the 15 years to pick it up time and again but to no avail. Last time I even made a cheat sheet for myself (a link here as a proof of effort): https://www.dropbox.com/s/ceiijwn8s31j8hv/emac_memo.svg?dl=0 Given the platform availability I'm pretty sure C++ will eventually reach th…

With all the activity with C++ development it'll hardly ever stabilise. Ever since C++11 it keeps changing at a frightening pace.

And you don't really need Emacs for Lisp, there are multiple other options (but yes, I'm using Emacs for C++ too).

Btw., quite a nice cheat sheet. What did you use to make it?

Re: The Joy and Agony of Haskell in Production

#29

Post by logicchains »

rwmj wrote: post #19

Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…

>In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand.

If you're hiring OCaml programmers who can't understand (or learn to understand) functors, you're probably doing something wrong. Even using the stdlib Hashtbl requires an understanding of functors.

Re: The Joy and Agony of Haskell in Production

#30

Post by wereHamster »

dasmoth wrote: post #25
wereHamster wrote: post #20

I don't agree that TH is bad. It's bad for generating real code (like I wouldn't use it to generate complicated logic), but just like you don't write Eq,Show,Ord instances yourself and instead let the compiler derive them for you, you use TH to generate JSON instances. I see TH more as a extension of deriving so I can easily derive custom typeclasses than for generating real code.

This case seems to increasingly be handled by DeriveGeneric. I realise the performance isn't quite the same, but so far my experiences of GHC generics have been pretty positive.

What's the performance overhead of instances based on Generic instead of TH? In PureScript for example generic instances are so slow it makes them unusable.
Post reply on HN