Are you able to find consistent work building web applications with Haskell? It seems that many organizations are reticent to build on those sorts of technologies (not quite sure what else I'm including - maybe OCaml?) for very rational reasons - it is hard and expensive to find employees who are capable of being productive in them.

There seems to be a very common perception that it is hard and expensive to find employees who can be productive in less mainstream languages, but I rarely see evidence to back that up. I can't speak for Greg, but in my experience, hiring is hard in every language, but not materially moreso in Haskell.

It's interesting, I meant my question to be about finding companies using Haskell or willing to hire contractors that build projects for them using it, but of course I did take it in the hiring direction, so it's my own fault. Rephrasing: Is it easy to find work using Haskell, despite the perception (whether deserved or no) that it is difficult to hire for, which may limit the number of companies willing to build in it?

It is very interesting, because the dominant narrative seems to be both that it's hard to hire for and hard to find jobs in, which can't both be true without massive communication inefficiencies, which I'm fairly sure don't exist. My experience has been that it's somewhat harder to find a job writing Haskell than it is to find a job in a mainstream language, but that it is still very doable.

This doesn't seem inconsistent at all. It's a classic feedback loop - it is hard to hire because most people don't want to invest in becoming experienced in a technology that not many companies are using, and it is hard to find a job because companies don't want to invest the resources in using a technology that not very many potential employees are experienced in. Very similar to social network chicken/egg problems. Seems to usually be solved by either investment from one or more large companies with an interest (Sun, Oracle), or a "killer app" (Web browsers, Rails, college students for Facebook). My little theory here is woefully inadequate to explain Python's and Go's success, so maybe another way out of the trap is "lots of people just really like it". Not sure if that will or won't work for Haskell...

My point is that "hard to hire" implies more jobs than candidates, whereas "hard to find jobs" implies more candidates than jobs. They can't both be true. You can say things like "there are few candidates" or "there are few jobs" in an absolute sense, by comparison to other languages, but that actually isn't very relevant.

This is an oversimplified model because it doesn't take into account engineer skill level, which actually does seem to be the primary problem. Companies want skilled engineers, but it's hard to become skilled without having a job in the language first. So we end up with several companies trying to hire seniors, and several juniors looking for jobs.

Both "hard to hire" and "hard to find jobs" are satisfied by a disjoint set of job locations to candidate locations.

That is, there could be plenty of X jobs in City Y, but that does little for the X candidate in Z city. Flip candidate/job as desired.

That's true, and there does seem to be a disproportionate number of Haskell jobs in Singapore, but overall I don't think it has a huge effect.

More likely you are just seeing a fairly common network effect, where once you are in it is easy to see many connections.

So, if there are some fairly good quantitative treatments of this, I'd be interested. I suspect it isn't too shocking. Probably more than the parent poster and friends think. Probably less than you do. :)

I actually really don't have much of a hypothesis at all. I asked my original question out of pure curiosity, and my reply was along the lines of it seeming very plausible for there to be both a shortage of candidates to hire and a shortage of companies hiring. But I also think the opposite is plausible. I think so far the most specific answer to my initial question of "is it easy to find Haskell work?" is "yes, in Singapore it is".

Anecdotally, as somebody who has tried to find a Haskell job, there seems to be a LOT of competition for them.

It's about accountability.

There are two types of it: a leader either recognizes and understands the gain to be had from using something like Haskell and has the resources to hire someone really good at it (who is therefore accountable, but he/she knows how to replace that person if they leave), or the leader themselves is an implementor in the esoteric technology and is comfortable being an accountable party themselves.

You rarely see the first type, more often it's the second type. Being accountable means that even if all of our programmers left us, I could at least keep the lights on without panicking (funny enough, that's actually easier to do in Haskell than a large Python / Ruby codebase).

BTW, it isn't hard to find them but it is expensive. These are people that have a level of motivation above the average and subsequently have a level of knowledge and skill also above the average. Basic economics can be used to answer why they are more expensive. Particularly when you start looking at specialized fields with a specialized technology: applied mathematicians that are also skilled Haskell programmers, or kernel hackers that also understand Haskell well.

I agree with every word you wrote.

To take it further, assuming both that projects built by experienced Haskell programmers are "better", and that those experienced Haskell programmers are more expensive, are those projects actually "better" enough for the company to break even. For the vast majority of projects, the answer is almost certainly "no", because most projects don't live or die on their technical merits. I think this limits the supply of companies further than even the perception-of-difficulty effects.

Projects don't live or die on technical merits. But more often than not, they are born or not on technical merits. Remember that lots of IT projects fail, often with no result at all to show.

That fact it easy to ignore when you interact only with competent developers.

Out of curiosity, as someone who uses Yesod, do you have any issues with it taking a really long time to compile?

Or do you not use cabal sandbox for Yesod dev projects?

I like to sandbox all my dependencies per app, but I just couldn't get over the fact that each new sandboxed install of yesod-platform took the better part of an hour to compile on my MacBook, and actually crashed my micro VPS instance.

There is a difference between installation and compilation. I install into a sandbox once, and then I don't need to do it again for a long time, so it isn't a big concern on a commercial project (make sure to use the -j option though!). You can deploy a final build image to a 'micro', but you do need a separate build server with some RAM to perform the build. You could just use a VM on your Mac.

The compilation time during the development cycle is a greater issue for me. I am testing out a way to speed that up now.

OK, thanks for the response. So it's not just me, a new install of yesod-platform is supposed to take a lot of time and RAM. I was just a little shocked by it, since a new rails install is pretty quick, even on a micro VPS.

I wasn't bothered by the time it took to recompile my app while running yesod dev, especially since it recompiles automatically when it detects a file system change. But my yesod app is trivial, maybe this becomes more of an issue with a substantial app. Worth it, though, for the compile-time syntax and type checking. And probably much faster compared to most rails test suites, which you'll have to rerun anytime you make a non-trivial change anyway.