
Haskell in Production - arkhamist
http://34cross.in/zero-to-haskell-in-production
======
mrj
As far as I can tell from this, the authors worked really hard to implement in
Haskell something that is trivial and well-understood in Python and other
languages.

Maybe the article could talk more about their specific needs, but this looks
like a crud app made very complicated by the choice of unusual software for
the task. Maybe it did something awesome, but this doesn't tell us what that
was. (They had to write their own ZeroMQ broker, after all. That was certainly
costly.)

I don't understand the claim in this article that concurrency in Python is
hard. There are many reasonable ways to do it for the web, from
multiprocessing using something like uwsgi or the excellent gevent. There are
certain things that are hard, but for common patterns like web services, there
are many awesome solutions to choose from.

And I don't understand why memory footprint is seriously a factor here. Server
runtimes may use all the memory available to go fast. As long as it fits,
footprint seems a lot less important than other factors. The cost of buying an
extra stick of ram is miniscule compared to the cost of having to implement
libraries to support a language choice.

The choice of a pure functional language like Haskell to do lots of IO seems
like a strange choice given that Haskell makes side effects like IO more
difficult than other languages. I'm curious to know how that affected the
implementation. I'd like to use more functional languages, but since my job is
primarily IO of some sort, watching people struggle with writing to sockets
leaves me more than a little hesitant.

Basically, this article is missing a lot of details to support the argument
they have made.

"The satisfaction we feel after a good day of Haskell is unparalleled, and at
the end of the day, that's what it's really all about isn't it."

Actually, since they appear to be working on a startup, I would think that a
functioning business and time to market would be more important.

~~~
mbrock
"The choice of a pure functional language like Haskell to do lots of IO seems
like a strange choice given that Haskell makes side effects like IO more
difficult than other languages. I'm curious to know how that affected the
implementation. I'd like to use more functional languages, but since my job is
primarily IO of some sort, watching people struggle with writing to sockets
leaves me more than a little hesitant."

Haskell has excellent I/O support. How do you mean that Haskell makes I/O
difficult?

~~~
peteretep
He means you have to climb the IO Monad learning curve.

~~~
mbrock
Learning is fun! And Haskell's IO functionality is pretty easy. They teach it
in the very first programming course at Chalmers in Gothenburg. It's covered
in any introductory Haskell book.

~~~
peteretep
Yes it's covered in any Haskell book - what use would a language book be
without covering IO? How far back in the book it comes, relative to other
languages, is the telling piece. LYAH has it as Chapter 9, after algebraic
data types, higher order functions, functors, and recursion... I note that in
the one week introduction I did for my MSc at the University of Oxford, they
didn't cover it, considering it to be too much to fit in to the week.

Having taken the rite of passage that is writing my own monad tutorial, I
would agree, the concept is both easy and intuitive. Getting it in to your
head, however, takes considerably more work than in any other language I've
used.

~~~
nightski
Waiting until chapter 9 isn't so bad when you realize that many professional
programmers including myself have been doing this for 20+ years and are still
learning the best way to structure effects within a program. What's the rush
anyways?

------
daniel-levin
I must respectfully disagree that Haskell's memory footprint is simply 'low'.
This is because the memory footprint of a given Haskell program is not at all
transparent, and Haskell is notorious for leaking memory in a maddeningly
opaque fashion [1, 2, 3, 4]. Space leaks might be relatively straightforward
to diagnose and fix for a true domain expert, but I would not want to have to
rely on someone having such abstruse knowledge in a production application. It
goes without saying that a space leak in a production app is a really, really
bad thing.

Although, I suppose one's choice of Haskell is a function of one's own
risk/reward profile. Haskell and its failure modes are hard to understand.
That induces extra risk that some people (myself included) might be
uncomfortable with. That said, I am now enthusiastically following you guys
and hope to see the proverbial averages get sorely beaten.

[1] [http://neilmitchell.blogspot.com/2013/02/chasing-space-
leak-...](http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-in-
shake.html)

[2] [http://blog.ezyang.com/2011/05/calling-all-space-
leaks/](http://blog.ezyang.com/2011/05/calling-all-space-leaks/)

[3] [http://blog.ezyang.com/2011/05/space-leak-
zoo/](http://blog.ezyang.com/2011/05/space-leak-zoo/)

[4] [http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-
leak/](http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/)

------
Ixiaus
We use Haskell extensively for all of our cloud services software at Plumlife
and it has been one of the best engineering decisions of my career.

Amazing language and ecosystem.

~~~
michaelochurch
I'd love to hear more (and talk offline).

My company is in the very early investigative stages on the Haskell front.

You can reach me at my name (including middle initial) which is this HN name,
at gmail dot com.

------
sitharus
I've been learning Haskell off and on for the last five years, and despite the
steep learning curve for an imperative programmer it's well worth it. Once you
grasp the idea of what not how, and embrace type inference it just gets so
much easier.

The world seems to be heading towards functional programming, with Swift and
the increase in functional constructs in c#. Much easier when the compiler
does more work for you.

------
leereeves
"There is a joy in programming with Haskell. ... There's so much working
Haskell code out there, that you can just stare at days for and not really
understand (but always use!)."

Is that a positive quality of Haskell?

~~~
michaelochurch
I think that, while there was a lot of good in the OP, this part was poorly
communicated.

I'd guess that he's talking about something like the Lens library, which is
incredibly easy to use, and comes from a place of great aesthetic sense, but
whose type signatures take some time to really get. I had to work some things
out on paper to see how the general Lens type signature:

    
    
        forall f. Functor f => (a -> f b) -> s -> f t
    

applied to all the "magic" that can be done with lenses. And then you also
have Traversals and Prisms. There's lots of stuff that just works, but
requires some depth of knowledge to understand how the magic is built. I
imagine that Frames, as it matures, will be in the same category (you need a
lot of type-level programming to get type-safe data-frames).

That said, I _still_ don't understand how certain languages (that shall remain
nameless, but I'm not talking about Haskell here) implemented a type-safe
printf, but it was easy to use. In statically typed languages like Haskell,
you get just some immediate insight into what you don't understand. In a
dynamic one, you can be led to feel like you understand more than you actually
do.

~~~
mercurial
If you mean OCaml, the typesafe printf uses compiler magic.

------
lclarkmichalek
Yeah, I'm never sure about language extensions. I've been trying really hard
to avoid just adding them willy-nilly to solve various problems, but I've
found there are at least 4ish that I include by default on every new Haskell
project I write (and I'm up to 9 on my current project!). Sometimes it feels
like their existence is a hindrance to fixing some flaws in the base language
(Haskell without OverloadedStrings makes me sad)

------
tome
> increases productivity by a few orders of magnitude

I'm the biggest Haskell fanboy you'll come across, but this is only true if an
order is not much bigger than 1!

------
je42
> Manually testing: IO related failures

These are clearly ones that i would be testing as part of the test suite...

------
tmikaeld
Why was Golang not a consideration?

~~~
ffn
My guess is probably the same reason why the author writes "NONE" in the "Ease
of / Desire to programming" section for Java... because brackets, pointers,
for loops, using : to declare types, and other such C-derived language
constructs / tokens.

This may be a generalization, but from my experiences so far, it seems there
are two major schools of programmers in today's world: those who come from
Java / C, and those who come from Python / Ruby.

The Java/C school likely did a lot of low-level stuff, hardware, OS,
compilers, and the like college. If required, they can probably crack open the
gnu debugger and crank through assembly. They concern themselves primarily
with systems that the computer can efficient perform. In their work, the
reader will find lots of loops, indexing temp variables, and comments
documenting that does what. Today, they tolerate working with higher level
tools like Go, vanilla js, Rust, Typescript, etc.

The Python/Ruby school likely did a lot of math and scientific computations in
college. In their hard drives, you can probably find Matlab, R, or (more
recently) Julia files containing everything from implementations of Newton's
method to routines for calculating Navier Stokes. They concern themselves
primarily theory and models, and prefer elegant and beautiful models/code to
optimized performance. In their work, the reader will find tons of maps-
filter-reduce chains, "arrows", and few comments (they argue their code is
clear). Today, their higher-level tool chain include things like Haskell,
Coffeescript, HAML, etc.

~~~
peteretep
Rust has all the hipster functional programming aspects that this high-level
language hipster wants...

~~~
platz
Except for HKT.. the true litmus test of the highest of high lvl lang. We're
waiting Rust.. we are waiting.

