[ablekh]

Much appreciate your feedback and advice. I was considering using F# instead C# for my potential .NET-based solution. But not because of Microsoft's ML push for F# (which seems to be just a move to achieve feature parity with C# within ML.NET framework, which, by the way, is not as comprehensive as relevant Python ecosystem), but rather because of F#'s meta-programming features. However, the advantages of F# still do not overweight its IMO two main disadvantages: a much more limited (vs. C#) pool of available developers and limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products).

[retendo]

> a much more limited (vs. C#) pool of available developers

I don't plan to hire anyone in the foreseeable future but what I can say is that there's 2 people happily working on the F# codebase at the moment, that do not have any prior experience in the language (professional Swift/ObjC background and played around with other languages). Getting into it is quite easy if you're interested in FP. I wouldn't worry too much about that. Just get some people who are experienced in .NET and some people who are good in FP.

> limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products)

I use JetBrains Rider on a Mac, without major problems so far

[ablekh]

Fair enough. Thank you, will keep this in mind.

[oaiey]

Google Jetbrains Rider.

Do not worry about the pool. The limiting factor in finding good people is the good part not the programming language.

[ablekh]

Thank you for sharing your thoughts. I'm aware of JetBrains Rider. In fact, I have installed it on my desktop and used it to explore the above-mentioned .NET boilerplate templates (C#-based). Perhaps, I missed that Rider fully supports F#. Will check it out.

Re: finding good people - I certainly agree with importance of focusing on the good part. However, still ... having a significantly larger pool of developers statistically increases chances to find good ones (which is important, especially considering competition with big tech firms in hiring engineering talent).

[737maxtw]

Does it?

I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path.

For certain organizations that is exactly what they need.

[ablekh]

I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).

[Xixi]

There's another point of view: that by targeting people who either know, or are interested in learning F#, or any other less popular language (like Rust, Erlang, Julia, etc.), you massively increase the quality of your applicant pool.

Developers that just want to pay the bills learn the popular languages: Python, javascript, Java, C#, Swift, etc. Developers who plays with (or maybe find little projects to do with) the like of F# are statistically more likely to care about their craft, even if they don't necessarily have the possibility to use these at their current jobs.

If someone contact you specifically because they want to use an FP language, but they can't at their current job, it's a very good sign. Of course if you limit yourself to something like: 5 years of experience writing F# in insert field of interest here, it's going to be very tough to hire anyone...

[ablekh]

Generally, I agree with you, except for the argument that developers who play with (or do projects using) less popular languages "are statistically more likely to care about their craft" (do you have any data supporting this claim?). Being curious, while certainly a valuable trait, is not equivalent to "being caring" about some craft - it is a nice addition to the package. However, it is a bit more nuanced than that. For example, success or failure in using this strategy depends on startup's stage, funding, roadmap, team size, engineering culture as well as current or potential use of microservices architecture, which gives us much greater flexibility in a relevant technology stack selection.

[kqr]

But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem.

My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have".

Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want.

So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know.

What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.

[ablekh]

Thank you for sharing your feedback. Your approach certainly makes sense and I'm also not a fan of listing specific programming languages (as well as stacks, frameworks, platforms or products) as strict requirements. However, in my book, it makes sense only for mature companies and later-stage startups. Early-stage (especially, bootstrapped, small and non-VC-backed) startups simply cannot afford to spend time for training on the job.

[oaiey]

Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100.

There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.

[ablekh]

Good points. Thank you for bringing them up.