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

61–70 of 94 posts

Re: The Joy and Agony of Haskell in Production

#61

Post by rybosome »

mbrock wrote: post #21
brobinson wrote: post #6

Earlier quoted context omitted.

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

http://bazel.io

I've never used the open-source variant, but caching of intermediate targets allowing for speedy incremental builds is a big theme.

Re: The Joy and Agony of Haskell in Production

#62

Post by enigmo »

mbrock wrote: post #21
brobinson wrote: post #6

Earlier quoted context omitted.

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

I've seen Stack download prebuilt binaries for some packages but build others... always having prebuilt versions of text/aeson/vector/lens/etc would definitely speed up resolver upgrades.

Re: The Joy and Agony of Haskell in Production

#63

Post by efnx »

tome wrote: post #59
efnx wrote: post #55

Earlier quoted context omitted.

Hey, you're talking about my library Renderable - and I'm totally up to finding a more idiomatic way to express the problem. It just so happened that type classes were the easiest way to do that.

Ha, sorry, didn't mean to make it sound like I was talking about anything in particular! I just made up that example on the spot. A "Renderable" thing fits into a common pattern where you see typeclasses used in this way. (Are you talking about this library? https://hackage.haskell.org/package/renderable-0.1.0.0/docs/... I don't actually see a Renderable class there anyway.)

Ahh - I thought you may have read my articles on HN or Reddit - how self centered of me :)

Yes, there's no 'Renderable' typeclass but there are 'Primitive's. There are no laws that the 'Primitive' typeclass instances must obey but there are associated types that need to be satisfied. I tried to write this without a typeclass and I just couldn't get it to check, so I turned to TypeFamilies to encode the relation ship between types. I'd love to make it more idiomatic though!

[I'd love some feedback if you're so inclined](https://github.com/schell/renderable/blob/master/src/Data/Re...)

Re: The Joy and Agony of Haskell in Production

#64

Post by enigmo »

wereHamster wrote: post #42
jeremyjh wrote: post #38

Earlier quoted context omitted.

For Aeson instances you really should be using the Generics. I do agree though that there are useful libraries (AcidState/SafeCopy is one example) that cannot reasonably be used without TemplateHaskell. While TemplateHaskell should be avoided if possible, it isn't the only consideration in choosing a design and dependency tree.

The article does not go into detail why TH is bad, and neither do you. Why should I be avoiding it? What are the exact problems with it, except the occasional breakage with new GHC releases? Generics is also not without its faults (it inflates compile time/memory, for example, see problems surrounding aeson 0.10). If the article is correct when it says that /[TH is] a eternal source of pain and sorrow/, then you're t…

As a maintainer of a >130kloc Haskell codebase spanning thousands of modules and hundreds of packages, I avoid TH primarily for one reason: slow builds. Painfully slow.

For cases where GHC.Generics is an option, I always take GHC.Generics over TH. Yes, Generics can be slow at times too but this somewhat controllable with various GHC_OPTIONS. Either way, there is no loader and interpreter overhead... and a lot of Generics code compiles in less time than it takes TH just to load `text` or `aeson` ;-).

Other reasons:

  * Some TH libraries add implicit dependencies that are not tracked by the build system
  * GHCi/TH's loader is different than the OS loader, sometimes causing failures if a TH dependency touches C++ libraries
  * No cross compiling ability... not an issue for me but it's painful for those targeting Javascript (via ghcjs), ARM or smaller x86 embedded systems

Re: The Joy and Agony of Haskell in Production

#65

Post by sklogic »

fsloth wrote: post #58
sklogic wrote: post #28

Earlier quoted context omitted.

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?

What's the best alternative to emacs for common lisp development? "Btw., quite a nice cheat sheet. What did you use to make it?" Thanks. Inkscape.

LispWorks is really nice. I've seen some people using Dandelion with Eclipse (although never tried it myself). It's also possible to interact with SWANK in vim, if you're into such things.

> Inkscape

Wow. Never even thought of it in such a context. I'll definitely give it a try.

Re: The Joy and Agony of Haskell in Production

#66

Post by moomin »

tamana wrote: post #45
runiq wrote: post #35

Earlier quoted context omitted.

Not just essentially. All monads are functors.

Not in OCaml. It's a different concept.

There seem to be a hundred language definitions of Functor. Even Haskell's doesn't exactly correspond to the mathematical understanding of the term (if it did, Set would be a functor)

C++ is the worst offender, though.

Re: The Joy and Agony of Haskell in Production

#67

Post by ScottBurson »

klibertp wrote: post #22
sklogic wrote: post #14

Earlier quoted context omitted.

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.

Yes, CL does have its share of historical baggage and warts. Despite those, I think it's still the best dynamically typed language. The rich number types, with arbitrary-precision integers by default, single- and double-floats, ratios, and complex numbers all built in; macros; and multimethods -- CL still has major features that the other dynamic languages, rather inexplicably to my mind, have yet to embrace. It's also much faster than Python or (especially) Ruby, and would be much faster than JavaScript but for the massive amount of effort that's gone into JIT compilation of this now-ubiquitous language.

If you're coming from a Haskell, F#, or even Scala or Ruby background, you might appreciate my functional collections library for CL [0]. It expands the range of code that can easily be written functionally.

Even if you don't have that experience, you might find FSet interesting, but it will take a little longer to wrap your head around.

[0] https://github.com/slburson/fset

Re: The Joy and Agony of Haskell in Production

#68

Post by wiz21 »

incepted wrote: post #13
colehasson wrote: post #9

I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.

If the language you want to work in is so important, you should have picked the company first and the location second. Besides, data outlives code. By orders of magnitude. You seem to be in love with Haskell today, chances are you'll be using a different language in ten years but the data you'll be working with will probably have been around for much longer than that. Don't fall in love with programming languages, it…

That's a very insightful comment. I 100% agree. And I'd add that I'm still completely baffled to see that some very obvious data support issues are still not resolved in the industrial world (e.g Java) : * Computing with units (which is tough to put in a language, but so is compilation) * Computing with dates in a sensible way

Of course one can make computation on those types, but it is so un-natural that it scares me :

* BigDecimal for currency, let me laugh * Date/timestamp without proper casting rules * Types towers with inheritance, generics, etc. Pfff... * Still no fine library to represent an address * Representing mutable ordered lists in SQL databases is still quite painful (possible, sure, but there's so boiler plate code to write)

So the data representation/manipulation problem, which goes with the data longevity you observe, that's something to learn about...

There's no reason to love current programming languages :-( (but I do love Python :-) 3 of course :-))

Re: The Joy and Agony of Haskell in Production

#70

Post by 15155 »

akurilin wrote: post #23

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

I think Opaleye will work well without TH.
Post reply on HN