[tathougies]

I use Haskell exclusively on my SaaS app (http://sostenoto.com). The backend not only provides a simple REST API, but it also provides WebRTC signaling and a real-time graphical communications and presence protocol.

Haskell makes it so easy to write correct concurrent code it's not even funny. GHC's magnificent IO manager means I can handle 1000s of connections on one amazon instance. Can't understand why you wouldn't be using Haskell for server-side web development.

No other popular server-side language supports concurrency (see STM, MVar's, and Chans), transparent futures/promises for I/O (the entire IO monad in GHC is non-blocking), support for multiple processors (Just add +RTS -N<n> to make your program scale to n processors), and a blazing fast HTTP server (warp).

[johan_larson]

> Can't understand why you wouldn't be using Haskell for server-side web development.

I can't tell whether that's just a rhetorical flourish, so I'll answer straight.

To begin with, there are a couple of concerns that might kill an attempt to use Haskell.

1. I might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 2. I might need to work with an existing codebase in something like Java or Python. Not possible from Haskell.

If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side: 1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably)

On the costs side: 1. I have much more experience in other languages. It would take at least a year, maybe two before I'd be up to pro standards in Haskell. 2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; I might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm.

So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.

[fizbin]

My experience with writing real production Haskell code is this: your first large Haskell project will be a failure, largely from missed deadlines and being unable to properly judge what is going to be easy and what hard. (Unless you deliberately aim low and spend much more time than is really justifiable on something you could have done in some language you know better in a few days)

Your second one will take longer than it would have in PHP or J2EE or whatever else you're used to building web stuff in. It will, like the first, also be ugly but unlike the first project will eventually work. It'll also fall over catastrophically early on, but will be salvageable. Once past its initial deployment/perf issues, it'll sit and hum away quietly in a corner with much less care and feeding than traditional web technologies. (Though you'll keep wanting to go back to it, because it's more fun to work in that than whatever else you're working on)

The third production Haskell project will come together much more quickly. Unfortunately, by this time you'll probably be bringing other people on and this will be their first big Haskell project. (See above about what happens to first big Haskell projects) So the parts delegated to other programmers will fail to work, and there will need to be lots of hand-holding and discussion of type design at first.

Selling management on this is indeed difficult. I'll admit that I'm still not clear on how we sold the first (failed) project to management or how I convinced my boss to let me use Haskell a second time. I mean, I was there, but I don't know how I did it.

[noobermin]

To be fair, both issues you mentioned are "soft" issues[0], albeit important ones. That doesn't quite seem like the "10%" the GP is referring to, or may be it is, but it gave me the impression he was talking about technical issues, not soft ones.

[0] as in people/social/management issues

[tathougies]

It's hyperbole, but if you were in the decision seat (which the person in your hypothetical is not), I think it's best to stick with a powerful language to ease development. Not trying to incite a flame war, but I have to agree with Paul Graham on this one.

[andruby]

Elixir is getting increasingly popular as a server-side language with Phoenix. It has great concurrency, futures (Tasks [0]), smp and a fast http server (cowboy [1]).

[0] http://elixir-lang.org/docs/v1.1/elixir/Task.html

[1] https://github.com/ninenines/cowboy

[zeckalpha]

But limited static analysis.

[cm3]

Is there Haskell involved in the WebRTC code or is pretty much all JavaScript?

[tathougies]

The Haskell server provides the WebRTC signaling, which is the only part of WebRTC that is not handled by the in-browser APIs. Basically before a peer-to-peer connection can be established, you have to provide some way of sending messages between the two users.