That hiring myth is a killer. Project I'm helping on would have been much better off with F#. But the CTO is very scared they wouldn't find "F# developers". Des

That hiring myth is a killer. Project I'm helping on would have been much better off with F#. But the CTO is very scared they wouldn't find "F# developers". Despite any C# dev worth hiring would not have a problem learning. Despite that his second hire just happens to know F# anyways. There was also concern that "valuation of the company might tank due to use of non-standard code". I think these are incorrect ideas. I'd take some pay cut to work on F# code instead of C#. Everytime I write anything in C#, I keep thinking how easier and shorter it'd be in F#. Just this week, we lost a whole day to a mutation bug: inputParam.Bar = Baz // oops, now we just updated the callers notion of that .Bar property Yeah, we coulda caught it in code review. We could have tried to make things readonly, but C# 5 still doesn't have a simple readonly record concept like F#. I'd guess that if you advertise an F# job you're going to get more good replies, because people want to work on F#. And you can still leverage someone's knowledge of .NET, the frameworks and libraries and all that. So it's less risky than using, say, Haskell, where you're all alone - F#'s still compiling and consuming IL even with all its magic on top. When I was 7 years younger, I predicted that obviously F# will take over at least 20% of C# development 2010 - it was just too awesome for people to ignore. There was no reason _not_ to use it apart from legacy or bad management, but no one could ignore such benefits. I have, uh, recalibrated since. (The biggest technical hurdle I had was frameworks that didn't target .NET, but targeted C#. They'd depend on undocumented output of the C# compiler expression trees. Those were a bit of a pain to fix, but not too hard. Another annoying thing is the MVC teams decision, since C# doesn't have tuples, and dictionary creation syntax is too clunky, to pass arbitrary types as parameters (@Html.Foo(new { this="is", just="some", anon="type" }). Then they go using reflection to inspect the properties of the type. That's just dumb and has caused tons of bugs. And would have been avoided had C# a nice way to write lists or tuples or something. But the MVC team wanted it to "feel like Ruby". This isn't _hard_ in F#, it just looks as bad as it is.