

Silk: why we use Haskell - derwiki
http://blog.typlab.com/2009/09/why-we-use-haskell/

======
qjz
Nice synopsis of Haskell as a _language_ , but it doesn't touch on why they
chose it for server side web application programming, specifically. I'd be
interested in knowing if it's capable, scalable and stable enough to provide a
platform to build on for the next few years. Based on its history to date, are
there protections in place for backwards compatibility, or are they likely to
end up pinning to an obsolete version? Does the standard library support web
services (SSL, unicode, etc.), or will they need to turn to third parties or
code essential building blocks from scratch?

~~~
ionfish
One thing worth noting here is that the article dates from 2009; things have
improved a _lot_ since then vis a vis web development in Haskell. New
frameworks (Snap, Yesod) have sprung up, and the library and toolchain support
have improved immeasurably.

To answer some of your questions a little more directly (I hope someone like
dons with a more encyclopaedic knowledge can pitch in here):

* As a _language_ , Haskell is both very stable and very cutting-edge. This is because GHC (the only Haskell compiler people use seriously for production, at least as far as I'm aware) supports both the Haskell '98 standard, and the more recent Haskell 2010 standard—but it also supports a large number of language extensions [1] such as type families, existential types, GADTs etc. So

* In terms of scalability, some of the recent benchmarks for Haskell-based web servers have been very impressive. Whether or not this translates into real-world performance is something we'll see as more people start using them in production. Recent improvements to the GHC I/O manager make the case for Haskell more compelling in this regard than it used to be.

* It's pretty easy in Haskell to write wrappers around C libraries, such as OpenSSL. There are also moves to implement more of these core parts of any web stack in pure Haskell, although getting them to feature-completion is a process that will take time.

A couple of recent reads spring to mind: a Stack Overflow discussion [1] where
Alex Payne asked about Haskell tools to make programs production-ready, and
Johan Tibell's article [2] on which Haskell libraries one should use.

[1]
[http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/ghc-l...](http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/ghc-
language-features.html)

[2] [http://stackoverflow.com/questions/5808825/what-are-the-
best...](http://stackoverflow.com/questions/5808825/what-are-the-best-haskell-
libraries-to-operationalize-a-program)

[3] [http://blog.johantibell.com/2011/04/haskell-libraries-you-
sh...](http://blog.johantibell.com/2011/04/haskell-libraries-you-should-
use.html)

~~~
dons
Specifically, with respect to openssl and unicode

* The language standard specifies Unicode strings

* The Haskell Platform library standard adds support for Unicode IO based on packed text buffers

* OpenSSL is provided via the venerable hopenssl library

And there are many happy web users, such as Janrain, Galois, typLab, Bump,
Deutsche Bank and others.

The ecosystem is in a pretty nice place now.

------
technomancy
Further proof of my theory that GHC's license has a clause buried in it
stating that you must post an explanation of monads on your blog in order to
use it.

~~~
Confusion
I'm not sure whether you are serious, cynical or tongue-in-cheek, so I feel it
necessary to point out that they are not actually explaining monads. They
provide an answer to the question that everyone will ask: "how do you do I/O
in a language in which all computations are supposed to be free of side-
effects, when I/O is obviously a side-effect?" The answer to that question is
'monads', but that's as far as they go. They don't actually explain anything
about monads.

------
joelburget
"And most of all, Haskell makes programming fun!" - If you're doing a startup
make sure you choose a language you enjoy. You're going to be spending a _lot_
of time using it.

(Also applies to cofounders and the application itself.)

~~~
BasDirks
I was gonna quote exactly the same, to affirm this. Haskell is an absolute joy
to program in. Nothing in the code of a Haskell program feels like "extra" or
"too much".

------
russellallen
The most important sentence for me was "Two of us (me and Sebas) are enrolled
in the Software Technology master program at Utrecht University, where we
often use the programming language Haskell."

What you're familiar and comfortable with is one of the most important
considerations in language/platform choice.

------
j_baker
Thank God. An article advocating Haskell that doesn't descend into some
variant of "You will go to Hell if you aren't using a strongly-typed, pure,
and lazy programming language."

------
joeburke
Predictably, this blog post reads like a Haskell pamphlet and it hits all the
Bingo marks: purity, no side effects, ah but yes side effects with the IO
monads, monads, concurrency, the awesome community (seriously? Have they
actually looked into it? The #haskell irc channel is moderated by Tony Morris,
a lunatic who's been banned from many mailing-lists and channels because of
several psychological disorders he suffers from), etc...

Even more predictably, not a single word on more pragmatic reasons to choose
Haskell as a startup, such as: web and networking support, logging, database
access, etc...

The odds of a startup succeeding are already vanishingly small, why make it
even harder on yourself by picking an exotic language that's all but unknown
in the work force?

<shakes head>

~~~
Peaker
"Haskell has no side effects" is true, but only in the sense that they are no
longer side effects but simply "effects" as they are marked a such.

The idea isn't to get rid of effects but to quarantine them, separate them
from simple functions into "procedures". This means you get to have real
functions in Haskell, and they truly are easier to compose together than what
other languages call "functions" but are actually procedures.

As for concurrency, Haskell is really in a unique spot, where you can get the
performance of threads and the simplicity of processes: the immutability of
everything not explicitly created for inter-thread communication gives you the
same safety of IPC, but the shared memory gives you threads' performance.

I think the benefits outlined on the page may not be specific to web
development, but they definitely apply to it too.

I haven't seen Tony Morris abuse anyone in the community, and the IRC channel
is an amazing combination of immense knowledge and patience with newbies.

~~~
joeburke
> I haven't seen Tony Morris abuse anyone in the community, and the IRC
> channel is an amazing combination of immense knowledge and patience with
> newbies.

Seriously? Here is the latest example on scala-debate, just two months ago,
where he went so far off the deep end that Martin himself had to step in and
tell him to cool down:

[http://groups.google.com/group/scala-
debate/browse_thread/th...](http://groups.google.com/group/scala-
debate/browse_thread/thread/db4af6597d942357)

He dishes this kind of abuse on a regular basis on lists, irc (especially
#scala) and sometimes even on his own Twitter feed.

Anyway, back to the topic at hand: yes, I know the theory behind immutability
and isolation and how it can enable easier parallelism. I have yet to see
practical examples of that in Haskell and convincing stats that show a boost
in performance compared to more traditional approaches (such as Java+nio or
even Scala actors).

My questions still hold regarding Haskell's adequacy in production, e.g. with
regards to database, logging or continuous integration, and I'm not the only
one: Alex Payne recently expressed the same concerns on SO:

[http://stackoverflow.com/questions/5808825/what-are-the-
best...](http://stackoverflow.com/questions/5808825/what-are-the-best-haskell-
libraries-to-operationalize-a-program)

~~~
michaeldhopkins
Yes, but nothing like that is happening in #haskell. I've asked some really
stupid questions there, sometimes more than once, and been treated well. The
"worst" treatment I've received is an admonishment to read the Haskell site
for a more trivial question.

~~~
dons
There are 16 official moderators on the #haskell channel, as well. I apologize
(as one of those moderators) if the OP has had a bad experience: with so many
people in the channel, not everyone gets exactly what they need, however, we
do try very very hard to be friendly.

The principles of the channel require this,
<http://haskell.org/haskellwiki/IRC_channel#Principles> \-- if an op has
treated you unfairly, please let us know, and we can correct the situation.

