What about the risk of hiring schlubs who can watch enough Railscasts to duct tape things together, but don't know anything about writing solidly-engineered, maintainable code?
The hiring pool is absolutely swimming with these guys because demand for Rails developers is so high right now. You are more likely to find a better OCaml developer for cheaper than you can find an equivalently skilled Ruby developer just by virtue of being a place offering professional work in OCaml. To attract a similar caliber of Ruby developer you need to offer some crazy perks like sponsored open-source work or some really interesting problems which 90% of early-stage startups don't actually have.
You might think it's foolish to worry about the quality of code when you are just trying to rush to market, but as soon as you get to market you need to start iterating, and that's where you find yourself immediately saddled with technical debt. Worse—and I say this as a professional Ruby developer for nearly a decade—Ruby provides very little in the way of guarantees that developers won't do really stupid things. If you don't have a solid test suite you are dead in the water for maintaining a large app because the interpreter by itself gives you nothing. All those awesome libraries which exist for Ruby but not OCaml? The half-life on those things is like 18-months in the Rails community, meaning you are in constant maintenance mode to keep up with the flavor of the month or else face maintaining an old stack yourself once the original creators abandon it and the community moves on.
Not that this doesn't come with benefits, but you're overselling them to justify picking the modern no-one-ever-got-fired-for-buying-IBM choice compared to the risk of using something less well-known but certainly with critical community mass and much better maintainability characteristics.
The hiring pool is absolutely swimming with these guys because demand for Rails developers is so high right now. You are more likely to find a better OCaml developer for cheaper than you can find an equivalently skilled Ruby developer just by virtue of being a place offering professional work in OCaml. To attract a similar caliber of Ruby developer you need to offer some crazy perks like sponsored open-source work or some really interesting problems which 90% of early-stage startups don't actually have.
You might think it's foolish to worry about the quality of code when you are just trying to rush to market, but as soon as you get to market you need to start iterating, and that's where you find yourself immediately saddled with technical debt. Worse—and I say this as a professional Ruby developer for nearly a decade—Ruby provides very little in the way of guarantees that developers won't do really stupid things. If you don't have a solid test suite you are dead in the water for maintaining a large app because the interpreter by itself gives you nothing. All those awesome libraries which exist for Ruby but not OCaml? The half-life on those things is like 18-months in the Rails community, meaning you are in constant maintenance mode to keep up with the flavor of the month or else face maintaining an old stack yourself once the original creators abandon it and the community moves on.
Not that this doesn't come with benefits, but you're overselling them to justify picking the modern no-one-ever-got-fired-for-buying-IBM choice compared to the risk of using something less well-known but certainly with critical community mass and much better maintainability characteristics.