I don't have direct experience with this, but it makes sense in theory. PHP is an easy language to find developers for, but it's incredibly annoying to figure out how competent the developers you're interviewing in that ecosystem will be. But languages like Haskell and Scala have a (perceived or real) barrier to entry, so you typically have a higher median ability among developers in those languages.
Anecdotal but I casually attend Boston Haskell and I can't remember the last time someone was out of work other than 'funemployment' (e.g. a startup goes bust and they have accrued more than enough money to just sit around, stretch and work on pet projects). The second they 'need' a job, they'll casually mention it and I think ~3 out of the ~7 times this has happened, someone in the crowd went like "oh Bill, yeah come in to <his office> Monday and meet our CTO". No recruiters, no wait. The CTO trusts Joe has heard Todd ask enough insightful questions consistently enough that he's going to be a good hire. Tuesday 9AM HR, 10AM pull the repo down, setup stack, start poking around Haddock and start closing the easy tickets. Good talent (10 of the 15 applicants are quality) might respond to Minsky but those other 9 guys will be picked up almost invariably in well under two weeks
I think any niche language person would be delighted to be paid equivalent to Java or C# rates for their city or industry, to hack Haskell or OCaml or Lisp or whatever.
If you're a beginner along both fronts (which is great: Haskell is a wonderful place to start), you might need to look at the talk topic ahead of time and choose ones which seem the most accessible.
If you're just a beginner in Haskell but comfortable with general math and CS topics, chances are that many talks won't be too Haskell-specific and you'll learn something interesting even if you don't get all the Haskell details. I've attended talks about things like succinct data structures, concurrency models, FFT algorithms... etc. All of these used Haskell and Haskell concepts, but weren't just about Haskell; you would have gotten something out of them even if you didn't know much about Haskell specifically.
I don't think most of the talks will be great for learning Haskell (unless that's their explicit aim) so if you actually want to learn the language you'll also need to do some reading on your own, but going to the meetups will still be valuable.
No one will ever admit publicly they are having a hard time hiring because of poor technical choices, that would be suicide.
I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly large selection of libraries and many people having already made the mistake you will make. This means when you run into an issue, there are already several posts on stack overflow about it, and you move on without issue.
The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects has that property.
Also, one of the really intriguing thing about splitting your service into smaller micro-service based architectures, is that you can mix and match different languages. Which gives you the ability to pick languages which suits a solution.
A good example is the TensorFlow system by Google. Model building usually happens in Python, but you then load that model into a thin C++ layer which serves the requests on the network as a standalone application. The same approach can be taken with some of the more advanced languages.
Even better, as a startup, the least of your worries straight away is horizontal scaling. Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling? This help the micro-service model even more, as there is less reason to worry about the communication overhead.
But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?
Because that node might die any second.
Unfortunately, this is HN so we know you're wrong:
At this point, I'm fairly certain your first hire should be someone to take the engineering load off of you. Engineering will be the only thing you really, truly understand about your business and so it will be the only thing you'll be able to effectively manage others doing.